GitLab

Friend request notifications from deleted users stay in the inbox,
and contain a url to the deleted user's profile.  We should just
delete these notifications, because they're no longer useful.

Change-Id: I224197238e3d5ca2f90bd28514a07f6d5d6b9852
Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

Bug #872619

Regression from 79810c3d



Basically, a default parameter of null was given, then trim
was called, which made it into the string '' which then failed
the test is_null in the files it was used.

This reorders the functions so that the trim is called after
the test to see whether the default should be used. This means
that the default value is never trimmed, and can be null.

One exception to this, is the param_boolean which doesn't test
to see whether it is the default that is returned, so a check
is made first to see whether it is null.

Change-Id: I66d7253a8414dec7eb3ea67ebd363ea068a32012
Signed-off-by: Hugh Davenport <hugh@catalyst.net.nz>

Instead of displaying content inside the editors on these pages,
it is useful if the user can see the html content as it would be
displayed to someone else.  The default on these pages is now to
display the various resume fields as html, with an edit button
beside each field to open up the editor.

Also combines some code to create & submit several similar resume
forms into functions in artefact/resume/lib.php

Change-Id: I649d7788a7e70dfd5dd3eb1ce648f37a7c057aa0
Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

These strings should have been part of d6446942
and can be seen as missing strings on http://mahara.example.com/tags.php



Bug #869925

Change-Id: I171bdf6278dd94b477a9f9164e171dfa85b77885
Signed-off-by: Francois Marier <francois@catalyst.net.nz>

Thanks to Melissa Newman for the fix.

Change-Id: Ied9197dd0e95df388e741af807ef498aeb85a102
Signed-off-by: Francois Marier <francois@catalyst.net.nz>

* changes:
  Remove view title display logic from my views template (bug #860154)
  Overwrite the profile view title on the Share page (bug #860154)
  Move the check for deleted groups when creating a View
  Get moderating roles from group function instead of the view

As a result of profile view access changes in bug #807278, profile
views are displayed on the share page.  So the 'editing' version
of view titles needs to be displayed in two places (my views/
group views etc., and on the share page).  It makes sense to use
the same View methods in both cases, and remove the old logic to
get the view title and url from the template.

Change-Id: Ifa36651dc3358acd71ca63407df79799ddd47299
Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

The profile view title is now displayed on the share page, due to
recent changes in profile view access (see bug #807278).  However
the view title from the database is now displayed on the share page
instead of the translatable string.

Change-Id: Ic691469731923faa0cef0c204b1207a9152e9fe2
Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

When constructing a View, we only need to perform the deleted group
check when pulling a view record out of the db, not every time we
create a View.  This change allows faster creation of View objects
in those cases where we already have all the data at hand.

Change-Id: I4d13446f31d841323692923a1cfc2647a2f3b2ed
Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

When deciding who can moderate comments on a group view, the
'moderating' roles are stored in the view object, but they don't
need to be, because they only depend on the group settings.  So
we can remove moderating roles from the View object, and get them
directly using the group id when required.

Change-Id: I69f5cd467e474a1fd9c0c589322c6a3935aa3482
Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

When creating a new BlockInstance object for a view, pass the view
object to the BlockInstance constructor when we already have it
handy.  This stops the BlockInstance from having to pull the view
out of the database again in its get_view method, and can save
several queries when rendering a view.

Change-Id: I717f154031794afec1ca0d353c1d358f297c5c1e
Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

Merge changes I308cf44f,I21f8636e,I5214c5b0,I81b44928,I8725e566,I3ec7d13d,I3ec49f59,Ia1611a6a,I3f8a15de,I7e5e5ff8,Id2ef0453

* changes:
  Allow update of group note permissions (bug #736665)
  Show artefact owner when selecting html artefacts (bug #736665)
  When configuring a read-only textbox, allow copying (bug #736665)
  Display textbox notes as read-only in config form (bug #736665)
  Return sanitised copy of description from artefactchooser (bug #736665)
  Get editable status along with artefactchooser artefacts (bug #736665)
  Stop users from editing note text in the wrong context (bug #736665)
  Allow editing of a textbox block when artefact not found (bug #736665)
  User can_publish_artefact method too restrictive (bug #865911)
  Use artefact method to get user's edit/publish permissions
  Allow use of group_user_access when logged out

Previously the only group artefacts were files, and group file permissions
can be updated within the filebrowser elements.  Now that there are group
notes, the permissions need to be able to be modified.  Done as a pieform
element in case other group artefact types are added in future.

Change-Id: I308cf44f95d29a4d13722726c9f007e248ee81fe
Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

In the artefact chooser for the textbox configuration form, add the
name of the artefact owner beside the title of each artefact.  This
makes it easier to distinguish between notes with the same title, and
more obvious when selecting (for example) group artefacts for inclusion
in a personal view.

Change-Id: I21f8636e7d9ee49237c636c2c56949c62ff1612b
Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

The fix in commit 884ccae4

 was
incomplete. It didn't pick up when there was an existing ? in the
baseurl. This patch adds that check.

Change-Id: I9666ae146ecf7ba8d8654e2cf97806f91f468d03
Signed-off-by: Melissa Draper <melissa@catalyst.net.nz>

Thanks to Melissa Newman for the solution!

Change-Id: Icc8f03e7b5a69f653ed37cd00db148e092de8ed3
Signed-off-by: Francois Marier <francois@catalyst.net.nz>

Some more changes were necessary. It's the same
file as for review 760 for Mahara 1.4

Change-Id: I0ee9d521b619f9afc3e8038122f00f4b0b0cfeff
Signed-off-by: Kristina D.C. Hoeppner <kristina@catalyst.net.nz>

When configuring a textbox containing a read-only artefact (or one
which has copies in other blocks), the user will often want to
create a new copy of the note instead of reusing the note.  This
patch adds a 'copy' link beside the read-only message, which will
unhide the tinymce box and set a flag to ensure that a new html
artefact gets created on submission.

Change-Id: I5214c5b0ae615cd9f32dfc5c71efc942b5961756
Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

When configuring a textbox that includes an html artefact owned by
someone other than the view owner, it must be made clear to the user
that the textbox cannot be edited within the current view.

In this case, the sanitised html from the artefactchooser is
displayed inside a grey box in the config form, and the tinymce editor
is hidden.

A help file has been added to explain why the user cannot edit the
selected artefact.

(When tinymce includes an toggle for its read-only mode, this can be
simplified)

Change-Id: I81b44928b7ac83ffaebba04d4ab34d3964743bf4
Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

When we are going to display an html artefact description outside a
tinymce window, in 'read-only' mode, we need it to be cleaned up by
the server in advance.  This patch adds returns a safe version of an
artefact description along with the original description, when
requested in the artefactchooser configuration.

Change-Id: I8725e56608214bba0a262de78e6dac8fcf5a4dd8
Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

When choosing an artefact for inclusion in a view, add a boolean
property to indicate whether each returned artefact is editable in
the context of the view.  So, individual artefacts are editable in
individual views provided the 'owner' is the same, group artefacts
are editable when the group is the same as the view's group, etc.

Change-Id: I3ec7d13d5401ddd007916f9382fd0673739dd815
Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

When a user is allowed to put (for example) a group textbox inside
a personal view, they should not be able to edit the contents of
that textbox inside their personal view, because it's not clear
enough that they may be about to modify a note with a different
owner.  This is especially dangerous when a group textbox has been
added to the individual views of different group members, and any
one member is able to modify the group textbox through their own
view.

When saving an html artefact from a textbox block configuration
form, this patch adds a check to ensure that the view owner is the
same as the artefact owner.  If not, an error is not thrown, but
the artefact description is not updated either.  A later commit
will ensure that users are made aware which html artefacts are
editable, and which are read-only before the configuration form is
submitted.

This change also allows users to include html artefacts in a
textbox even when they only have 'republish' permission on the
artefact.

Change-Id: I3ec49f59b04679853ecd57e300e72f23f6ff9c9d
Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

When a textbox block references an artefact that has been deleted,
or has become unpublishable by the current user, clicking the block's
configure button causes an error and fails to bring up the config
form.  Avoid this by catching the ArtefactNotFound exception, and
allowing the block to be reconfigured when it contains an invalid
artefact.

Change-Id: Ia1611a6abf2328c503655dacf01b2c414a603b0a
Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

The can_publish_artefact method on the User class, introduced in
commit aba54873

 (see bug #655631) is out of line with other
permissions on the site when it comes to institution artefacts.

Any institution member can include institution files on one of their
own pages, but this method (currently used when putting images into
forum posts) only allows publishing by institutional admins.

This change adds publishing permission on institution artefacts for
all institution members.

Change-Id: I3f8a15de573de6f58497ae45839647b462fa5e89
Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

The role permissions on group artefacts are stored in the artefact
object, so we might as well make use of that in the can_edit_artefact
and can_publish_artefact methods of the User class instead of forcing
a new query.

Change-Id: I7e5e5ff8e14fc55638a613a9253eb0c35fd60867
Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

group_user_access returns false when there is no logged-in user.  But
there are times when the code may still want to call this function on
a valid user id and group when there is no active user.

For example, when a logged-out user is looking at a public forum, we
still need to find out whether a poster has permission to publish a
particular image artefact in the post, and being able to use the
group_user_access function is handy in this case.

Change-Id: Id2ef045311fd05220b683a2a2dea4f12cef269f4
Signed-off-by: Richard Mansfield <richard.mansfield@catalyst.net.nz>

Typo with 'errorbadinstitutioncombo' - comp^bination

Change-Id: I40a1d5f1758590ad9157d922df2cd8cee3bc3b0b
Signed-off-by: Piers Harding <piers@catalyst.net.nz>