Search moodle.org's
Developer Documentation
Developer Documentation
See Release Notes
Long Term Support Release
- Bug fixes for general core bugs in 3.9.x will end* 10 May 2021 (12 months).
- Bug fixes for security issues in 3.9.x will end* 8 May 2023 (36 months).
- PHP version: minimum PHP 7.2.0 Note: minimum PHP version has increased since Moodle 3.8. PHP 7.3.x and 7.4.x are supported too.
/availability/classes/ -> condition.php (source)
Differences Between: [Versions 39 and 310] [Versions 39 and 311] [Versions 39 and 400] [Versions 39 and 401] [Versions 39 and 402] [Versions 39 and 403]
Base class for a single availability condition. All condition types must extend this class.
| Copyright: | 2014 The Open University |
| License: | http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later |
| File Size: | 190 lines (8 kb) |
| Included or required: | 0 times |
| Referenced: | 0 times |
| Includes or requires: | 0 files |
Defines 1 class
condition:: (7 methods):
check_available()
is_available_for_all()
__toString()
get_type()
get_standalone_description()
update_dependency_id()
completion_value_used()
Base class for a single availability condition.
All condition types must extend this class.
The structure of a condition in JSON input data is:
{ type:'date', ... }
where 'date' is the name of the plugin (availability_date in this case) and
... is arbitrary extra data to be used by the plugin.
Conditions require a constructor with one parameter: $structure. This will
contain all the JSON data for the condition. If the structure of the data
is incorrect (e.g. missing fields) then the constructor may throw a
coding_exception. However, the constructor should cope with all data that
was previously valid (e.g. if the format changes, old data may still be
present in a restore, so there should be a default value for any new fields
and old ones should be handled correctly).
All condition types must extend this class.
The structure of a condition in JSON input data is:
{ type:'date', ... }
where 'date' is the name of the plugin (availability_date in this case) and
... is arbitrary extra data to be used by the plugin.
Conditions require a constructor with one parameter: $structure. This will
contain all the JSON data for the condition. If the structure of the data
is incorrect (e.g. missing fields) then the constructor may throw a
coding_exception. However, the constructor should cope with all data that
was previously valid (e.g. if the format changes, old data may still be
present in a restore, so there should be a default value for any new fields
and old ones should be handled correctly).
| check_available($not, info $info, $grabthelot, $userid) X-Ref |
| Determines whether a particular item is currently available according to this availability condition. If implementations require a course or modinfo, they should use the get methods in $info. The $not option is potentially confusing. This option always indicates the 'real' value of NOT. For example, a condition inside a 'NOT AND' group will get this called with $not = true, but if you put another 'NOT OR' group inside the first group, then a condition inside that will be called with $not = false. We need to use the real values, rather than the more natural use of the current value at this point inside the tree, so that the information displayed to users makes sense. param: bool $not Set true if we are inverting the condition param: info $info Item we're checking param: bool $grabthelot Performance hint: if true, caches information param: int $userid User ID to check availability for return: bool True if available |
| is_available_for_all($not = false) X-Ref |
| No description |
| __toString() X-Ref |
| Display a representation of this condition (used for debugging). return: string Text representation of condition |
| get_type() X-Ref |
| Gets the type name (e.g. 'date' for availability_date) of plugin. return: string The type name for this plugin |
| get_standalone_description($full, $not, info $info) X-Ref |
| Obtains a string describing this restriction, used when there is only a single restriction to display. (I.e. this provides a 'short form' rather than showing in a list.) Default behaviour sticks the prefix text, normally displayed above the list, in front of the standard get_description call. If implementations require a course or modinfo, they should use the get methods in $info. The special string <AVAILABILITY_CMNAME_123/> can be returned, where 123 is any number. It will be replaced with the correctly-formatted name for that activity. param: bool $full Set true if this is the 'full information' view param: bool $not Set true if we are inverting the condition param: info $info Item we're checking return: string Information string (for admin) about all restrictions on |
| update_dependency_id($table, $oldid, $newid) X-Ref |
| Obtains a representation of the options of this condition as a string, for debugging. return: string Text representation of parameters |
| completion_value_used($course, $cmid) X-Ref |
| If the plugin has been configured to rely on a particular activity's completion value, it should return true here. (This is necessary so that we know the course page needs to update when that activity becomes complete.) Default implementation returns false. param: \stdClass $course Moodle course object param: int $cmid ID of activity whose completion value is considered return: boolean True if the availability of something else may rely on it |
