Search moodle.org's
Developer Documentation
Developer Documentation
- Bug fixes for general core bugs in 3.11.x will end 14 Nov 2022 (12 months plus 6 months extension).
- Bug fixes for security issues in 3.11.x will end 13 Nov 2023 (18 months plus 12 months extension).
- PHP version: minimum PHP 7.3.0 Note: minimum PHP version has increased since Moodle 3.10. PHP 7.4.x is supported too.
/availability/classes/ -> condition.php (source)
Differences Between: [Versions 310 and 311] [Versions 311 and 400] [Versions 311 and 401] [Versions 311 and 402] [Versions 311 and 403] [Versions 39 and 311]
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: | 260 lines (10 kb) |
| Included or required: | 0 times |
| Referenced: | 0 times |
| Includes or requires: | 0 files |
Defines 1 class
condition:: (10 methods):
check_available()
is_available_for_all()
__toString()
get_type()
description_cm_name()
description_format_string()
description_callback()
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 |
| description_cm_name(int $cmid) X-Ref |
| Returns a marker indicating that an activity name should be placed in a description. Gets placeholder text which will be decoded by info::format_info later when we can safely display names. param: int $cmid Course-module id return: string Placeholder text |
| description_format_string(string $str) X-Ref |
| Returns a marker indicating that formatted text should be placed in a description. Gets placeholder text which will be decoded by info::format_info later when we can safely call format_string. param: string $str Text to be processed with format_string return: string Placeholder text |
| description_callback(array $params) X-Ref |
| Returns a marker indicating that some of the description text should be computed at display time. This will result in a call to the get_description_callback_value static function within the condition class. Gets placeholder text which will be decoded by info::format_info later when we can safely call most Moodle functions. param: string[] $params Array of arbitrary parameters return: string Placeholder text |
| 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. They should not use any other functions that might rely on modinfo, such as format_string. To work around this limitation, use the functions: description_cm_name() description_format_string() description_callback() These return special markers which will be added to the string and processed later after modinfo is complete. 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 |
