mahara-contributors team mailing list archive

[Kristina Hoeppner <1516823@xxxxxxxxxxxxxxxxxx>]

** No longer affects: mahara/16.04

** Changed in: mahara
       Status: Fix Committed => Fix Released

-- 
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/1516823

Title:
  MNet: Separate the acts of locking a page, and granting view access to
  a page

Status in Mahara:
  Fix Released

Bug description:
  See also: https://github.com/MaharaProject/moodle-
  assignsubmission_mahara/issues/2

  The Mahara assignment submission plugin was originally written with
  the idea that submitted pages would always be locked. So, we used the
  presence of the lock record as a way to check for whether or not the
  page should be visible to a specific MNet user.

  With the new generation assignment submission plugin, the plugin now
  supports modes of operation where the Mahara page *never* gets locked.
  In this case, it was relying on a bug in the original code, where the
  view access record would remain present after you locked & unlocked a
  page, until another submission instance came along and subsequently
  locked the page.

  To handle this in a more correct manner, we need separate methods for
  locking a page, and for checking whether a user has access to a page.
  The way we've decided to handle this, is to delegate the access
  control to Moodle. When a user comes from the Moodle gradebook to view
  a submitted Mahara page, Mahara will make an MNet function call back
  to Moodle to check whether that user should be able to view that page
  or not. This will replace the current confused system of secret URL
  tokens and locks.

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