mahara-contributors team mailing list archive

[Aaron Wells <1262040@xxxxxxxxxxxxxxxxxx>]

Well, the problem I had originally reported does seem to be cleared up.
Specifically, if you put a file into a group, change its permissions for
group members to "view" or "edit", and then log in as a group member,
and try to put that file into one of your personal blocks, you will now
find that you cannot do that through the UI. The Javascript prevents you
from selecting it, and there's a "You cannot republish this" message if
you hover over it.

On the other hand, I can still add the image to my block by manipulating
the underlying HTTP request with Burp Proxy. The validation method that
is supposed to check for permissions
(BlockInstance->verify_attachment_permissions($id)) was updated in patch
9a2519b87f27 for Bug 1224750 (accessibility of public site files) so
that it checks against can_view_artefact() rather than
can_publish_artefact().

But... this problem is mitigated by the fact that even once I add the
image to my block, it won't be displayed. There's verification on the
display side as well, so the image is not shown and instead there's a
warning message that says I don't have permission to republish that
image.

So, still a little broken. But less so. So I'm going to lower this one
to "low" priority unless we get some specific reports of bigger problems
caused by it.

** Changed in: mahara/15.10
   Importance: Medium => Low

** Changed in: mahara/16.04
   Importance: Medium => Low

** Changed in: mahara/15.10
       Status: Incomplete => Confirmed

** Changed in: mahara/16.04
       Status: Incomplete => Confirmed

-- 
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1262040

Title:
  Problems with group artefact permissions due to misuse of
  $USER->can_view_artefact and $USER->can_edit_artefact

Status in Mahara:
  Confirmed
Status in Mahara 1.10 series:
  Confirmed
Status in Mahara 15.04 series:
  Confirmed
Status in Mahara 15.10 series:
  Confirmed
Status in Mahara 16.04 series:
  Confirmed

Bug description:
  While discussing the export to ZIP bug ( Bug 1013022 ) I realized that
  $USER->can_view_artefact() does not do what I thought it did. I
  thought that it was like can_view_view(), i.e. it was an easy way to
  tell whether a particular user is allowed to see the contents of a
  particular artefact.

  But it does not mean that, as evidenced by the fact that it's not
  accessed at all on the artefact detail page, view/artefact.php.
  Instead, this function refers to whether or not the user should be
  able to see the artefact in their own or a group's Content area.

  The reason it exists and has this name, is because of the group files
  permissions system (see
  http://manual.mahara.org/en/1.8/groups/inside_group.html#index-16 ).
  This defines three permission levels for a file: "View" lets you see
  the page in Contents and use it in Group pages, "Edit" lets you change
  the file's metadata, and "Publish" lets you use the file in your own
  Portfolio pages.

  Anyway, I misunderstood it as doing the same thing as can_view_view(),
  which checks whether a particular user can see a particular Page in
  display-mode. The similar functionality for artefacts, as seen on
  view/artefact.php, is to provide an artefact ID & a page ID, and to
  check whether the artefact is in the page and the user can view the
  page.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1262040/+subscriptions