It has never worked, because the data for text area fields is not
loaded into the $USER object.
Changing it so that the dropdown list does not include these types
of field.
There was an error in the JavaScript and custom user field
restrictions did not show correctly when editing the form.
Behat tests didn't cover custom user fields, so I added a
scenario.
1. Changed the 'delete' and 'eye' buttons to use an <a> link
tag so that it works without custom tabindex and shows a correct
mouse cursor. This also reduces the code slightly.
2. Changed the Cancel button on the dialog to use the mdl-align
class which is used in Atto dialogs. This results in the button
being centered, consistent with those dialogs.
When groupmembersonly is turned on, the 'restrict access' options
for group and grouping are supposed to appear only for sections
(which don't have groupmembersonly) and not for modules.
Prior to this fix, they appeared when creating a new module but
not when editing an existing one.
If there is invalid data in the availability condition (note: this
should not happen, but can do in unusual situations, such as
specifying a date after 2038 in 32-bit PHP), this should not
leave the course so broken that users cannot edit the activity and
update it.
Includes all the conditions that were in previous Moodle versions:
* Date
* Grade
* Completion (of another activity)
* User profile field
Also includes conditions that are used to reimplement
groupmembersonly:
* Grouping
* Group
For each condition, the component plus unit tests are included.
PLEASE NOTE: The code to actually check each condition is reused
from previous Moodle versions and has not been modified except to
pass codechecker. This is intentional, to reduce the risk of the
change and maximise the chance that behaviour is preserved. Some
of this code might not be very good and might need updating but
that can happen separately.
AMOS BEGIN
CPY [contains,core_condition],[op_contains,availability_profile]
CPY [doesnotcontain,core_condition],[op_doesnotcontain,availability_profile]
CPY [endswith,core_condition],[op_endswith,availability_profile]
CPY [isempty,core_condition],[op_isempty,availability_profile]
CPY [isequalto,core_condition],[op_isequalto,availability_profile]
CPY [isnotempty,core_condition],[op_isnotempty,availability_profile]
CPY [startswith,core_condition],[op_startswith,availability_profile]
CPY [completion_fail,core_condition],[option_fail,availability_completion]
CPY [completion_pass,core_condition],[option_pass,availability_completion]
CPY [completion_complete,core_condition],[option_complete,availability_completion]
CPY [completion_incomplete,core_condition],[option_incomplete,availability_completion]
AMOS END
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
