mahara-contributors team mailing list archive

[Richard Mansfield <620170@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

We need a good function to take a bunch of view access records and
simpify them down to a sensible minimal set.  This has always been a bit
of a problem, but it will become worse now that we are merging sets of
access records when adding views to collections.

The process for rationalising the access rules should be something like
this:

- Remove any records with a stop date in the past
- Remove start dates that are in the past from all records
- If the view allows comments, set allowcomments/approvecomments on all access records to the default (0/1)
- If any two records are identical apart from start/stop dates, and their date ranges overlap, merge them to one with the minimum start date and maximum stop date
- Remove any identical duplicates


There are a bunch of other simplifications that could be done, but I'd rather leave them alone for now because someone might have a use for them.  For example:
- If there's a public access record, we could remove all other records with a date range included in the public access date range,
- If there's a logged-in access record, we could remove all other records except public with a date range included in the logged-in access date range,
- If there's a 'whole group' access record, we could remove all group role access records for the same group with a date range included in the whole group access date range,
etc.


For now, we should also make sure this process doesn't mess with invisible access records.

** Affects: mahara
     Importance: Undecided
         Status: New

-- 
Merge/simplify view access records
https://bugs.launchpad.net/bugs/620170
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.

Status in Mahara ePortfolio: New

Bug description:
We need a good function to take a bunch of view access records and simpify them down to a sensible minimal set.  This has always been a bit of a problem, but it will become worse now that we are merging sets of access records when adding views to collections.

The process for rationalising the access rules should be something like this:

- Remove any records with a stop date in the past
- Remove start dates that are in the past from all records
- If the view allows comments, set allowcomments/approvecomments on all access records to the default (0/1)
- If any two records are identical apart from start/stop dates, and their date ranges overlap, merge them to one with the minimum start date and maximum stop date
- Remove any identical duplicates



There are a bunch of other simplifications that could be done, but I'd rather leave them alone for now because someone might have a use for them.  For example:
- If there's a public access record, we could remove all other records with a date range included in the public access date range,
- If there's a logged-in access record, we could remove all other records except public with a date range included in the logged-in access date range,
- If there's a 'whole group' access record, we could remove all group role access records for the same group with a date range included in the whole group access date range,
etc.


For now, we should also make sure this process doesn't mess with invisible access records.