Proposals/Multipage Views Take 3

Well, the way we wound up implement "multipage Views" is as Collections: http://manual.mahara.org/en/1.7/portfolio/collections.html

Collections achieve the main goal of multipage views, which is to create "mini-sites" of pages that are linked together sequentially. But, they have some important limitations:

• Each View can belong to only 1 Collection
• If a View belongs to a Collection, it will always be viewed as part of that Collection
• All the Views in a Collection have exactly the same permissions, so you can't give a person access to just one View in a Collection
• On a similar note, you can't Submit just one View from a Collection ( http://manual.mahara.org/en/1.7/portfolio/feedback.html#submit-a-page-or-collection-for-assessment )
  • The workaround is to make a copy of the View
  • But if you do that, you lose the Comments on the View. You also now have two copies of the View, which can get out of sync with each other.
• It's also rather arbitrary. One of the basic principles of Mahara is that you can re-use Artefacts in multiple Views. Why shouldn't you also be able to re-use Views in multiple Collections?
• And from a coding perspective, there's a lot of duplication involved. There is no permission record for the "Collection" itself; instead, duplicate access records are entered for each View
• And there is no URL for the Collection itself. Instead, you provide the URL for the first View in the Collection.

As part of the 2013 MyPortfolio funding, we're hoping to create the ability to Submit one View from a Collection. On analyzing this, it seemed like the cleanest way to achieve this would be to lift the arbitrary limit of letting Pages exist in only one Collection:

• Allow a View to belong to more than one Collection
• Allow a View to be accessed by its own URL, which will show it as a standalone Page rather than as one page in a Collection
• Allow separate access records for Collections and for each View in the Collection
  • If a page is viewed by its collection url (i.e. view/view.php?collection=1&view=1 ) you use the Collection's access record
  • If a page is viewed by its own url (i.e. view/view.php?view=1 ) you use the View's access record

This quickly proved to be more complicated than expected. The main sticky point is access control, which will need to be completely refactored:

• Access control records are stored in the view_access table.
  • This table simply has a "view" column which indicates which view each record belongs to
  • There are multiple records per view in view_access, each of which represents the access rights belonging to some class of individuals: Public, a specific user, a group, an institution, friends; and a separate start-date/stop-date
  • Additionally, some access-control details are stored in the view table itself: The overall startdate & stopdate (which can be used to disable all access regardless of other controls) and the overall "allowcomments" and "moderate comments" values.
• Every page in Mahara which accesses a View or Artefact, calls the function can_view_view(), to determine if the currently logged-in user should be allowed to view it.
  • Even when an Artefact is viewed on its own, a viewid is passed as part of the URL, specifically to pass into can_view_view() to see whether the artefact belongs to any View that the logged-in user is allowed to see.

My solution is to abstract access control into a Access Contexts. These would be similar to Moodle security contexts.

• One record in the new access_context table for each access context.
  • This table contains columns indicating the context type (view or collection) and the context's instance id (view id or collection id)
  • It also contains startdate, stopdate, allowcomments, and approvecomments, similar to the existing columns in the view table
• Multiple records in the new access_setting table for each access context
  • These correspond to the old view_access table, and represent the access rights of different classes of users.
• As a legacy support issue, it's trivial to write a SQL view called "view_access" which simulates the contents of the old view_access table using the contents of the access_context and access_setting tables.
  • However, most places that access the view_access table will still need to be rewritten to provide full support for Collections.
  • Also, any place that inserts/updates/deletes view_access
• Probably the easiest way to deal with can_view_view() would be to make it do a further check whether the view belongs to any Collection the user has access to.
  • This function is used in many, many places, including a great deal of Ajax scripts, so it would be easiest to do this rather than to rewrite every script that calls it, and every script that calls every script that calls it.
• In the long run, it may make sense to abstract Access Contexts even more, to encompass Artefacts for instance
  • Artefacts can already be viewed on their own in a "detail page", such as this one: https://mahara.org/view/artefact.php?artefact=271036&view=81194
  • Currently, Artefact detail pages rely on View access settings to decide whether you're allowed to see them. If Artefacts were given their own Access Contexts, then you could make them publicly accessible on their own, facilitating new use-cases for Mahara.