- Remove 'showmore' logic from the base availability_info renderable.
Other components rendering the availability information should handle the showmore/showless behaviour themselves.
- Deprecate JS module and string.
- Move availability_info header generation logic to a new protected function to improve code readability.
This allows an availability plugin to indicate that a selected condition
should be considered "private", and therefore should never be shown to
users who don't satisfy the criteria. The availability_groups plugin
uses this to protect visibility of groups that are not visible to
non-members.
Significant string changes:
* hidegrader_help,mod_assign - note about setting having no effect on
comments box
* configdefaultrequestcategory, configenablecourserequests,
configlockrequestcategory, lockrequestcategory, core_admin - clearer
explanation
* configenablecompletion,core_completion - including reason for setting
activity completion conditions
* emailstop,core - clearer wording
* setuplink_desc,tool_mobile - including where the app download page
link is displayed and leaving the setting empty
Significant string changes:
* importgroups_help,core_group - Correcting optional fieldnames
(removing picture, hidepicture and adding groupidnumber, groupingname
and enablemessaging)
* penaltyforeachincorrecttry_help,core_question - additional paragraph
about scoring logic
* resultdownloadready,tool_dataprivacy - wording corrected (no need to
go to a download page)
* auth_dbfielduser,auth_db - varchar data type requirement
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
