The previous API included a facility to filter a list of users
to include only those who are allowed to access an activity, i.e.
only people who belong to the required groups etc.
This change adds a new API function to return SQL that obtains
this list of users, so that it can be combined with other
queries.
Remove groupmembersonly usage in the core_availability API, and change
the update code (used in backup) so that it considers groupmembersonly
when restoring old backups.
This commit defines the new /availability root folder, with
/availability/classes, /availability/tests, and
/availability/condition where the condition plugins will live.
Condition plugin prefix is availability_, e.g. availability_date.
Rationale for this organisation:
1. I was originally going to put this in /lib/availability but
it has been pointed out that putting even more junk in lib
is probably bad.
2. 'availability' and 'condition' are the two names used in code
to refer to this system ($CFG->enableavailability).
3. The prefix has to be short enough to allow database tables
(although in practice I assume that condition plugins will not
normally contain database tables).
The new API includes a Boolean tree structure that controls the
availability of an item.
AMOS BEGIN
CPY [availabilityconditions,core_condition],[restrictaccess,core_availability]
CPY [enableavailability,core_condition],[enableavailability,core_availability]
CPY [configenableavailability,core_condition],[enableavailability_desc,core_availability]
AMOS END
