Search moodle.org's
Developer Documentation
Developer Documentation
- Bug fixes for general core bugs in 4.0.x will end 8 May 2023 (12 months).
- Bug fixes for security issues in 4.0.x will end 13 November 2023 (18 months).
- PHP version: minimum PHP 7.3.0 Note: the minimum PHP version has increased since Moodle 3.10. PHP 7.4.x is also supported.
/availability/classes/ -> tree_node.php (source)
Node (base class) used to construct a tree of availability conditions.
| Copyright: | 2014 The Open University |
| License: | http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later |
| File Size: | 256 lines (11 kb) |
| Included or required: | 0 times |
| Referenced: | 0 times |
| Includes or requires: | 0 files |
Defines 1 class
tree_node:: (6 methods):
include_after_restore()
update_after_restore()
is_applied_to_user_lists()
filter_user_list()
get_user_list_sql()
unique_sql_parameter()
Node (base class) used to construct a tree of availability conditions.
| include_after_restore($restoreid, $courseid, \base_logger $logger, $name,\base_task $task) X-Ref |
| Checks whether this node should be included after restore or not. The node may be removed depending on restore settings, which you can get from the $task object. By default nodes are still included after restore. return: bool True if there was any change param: string $restoreid Restore ID param: int $courseid ID of target course param: \base_logger $logger Logger for any warnings param: string $name Name of this item (for use in warning messages) param: \base_task $task Current restore task |
| update_after_restore($restoreid, $courseid, \base_logger $logger, $name) X-Ref |
| Updates this node after restore, returning true if anything changed. The default behaviour is simply to return false. If there is a problem with the update, $logger can be used to output a warning. Note: If you need information about the date offset, call \core_availability\info::get_restore_date_offset($restoreid). For information on the restoring task and its settings, call \core_availability\info::get_restore_task($restoreid). return: bool True if there was any change param: string $restoreid Restore ID param: int $courseid ID of target course param: \base_logger $logger Logger for any warnings param: string $name Name of this item (for use in warning messages) |
| is_applied_to_user_lists() X-Ref |
| Checks whether this condition applies to user lists. The default is false (the condition is used to control access, but does not prevent the student from appearing in lists). For example, group conditions apply to user lists: we do not want to include a student in a list of users if they are prohibited from accessing the activity because they don't belong to a relevant group. However, date conditions do not apply - we still want to show users in a list of people who might have submitted an assignment, even if they are no longer able to access the assignment in question because there is a date restriction. The general idea is that conditions which are likely to be permanent (group membership, user profile) apply to user lists. Conditions which are likely to be temporary (date, grade requirement) do not. Conditions which do apply to user lists must implement the filter_user_list function. return: bool True if this condition applies to user lists |
| filter_user_list(array $users, $not,\core_availability\info $info, capability_checker $checker) X-Ref |
| Tests this condition against a user list. Users who do not meet the condition will be removed from the list, unless they have the ability to view hidden activities/sections. This function must be implemented if is_applied_to_user_lists returns true. Otherwise it will not be called. The function must operate efficiently, e.g. by using a fixed number of database queries regardless of how many users are in the list. Within this function, if you need to check capabilities, please use the provided checker which caches results where possible. Conditions do not need to check the viewhiddenactivities or viewhiddensections capabilities. These are handled by core_availability\info::filter_user_list. return: array Filtered version of input array param: array $users Array of userid => object param: bool $not True if this condition is applying in negative mode param: \core_availability\info $info Item we're checking param: capability_checker $checker |
| get_user_list_sql($not, \core_availability\info $info, $onlyactive) X-Ref |
| Obtains SQL that returns a list of enrolled users that has been filtered by the conditions applied in the availability API, similar to calling get_enrolled_users and then filter_user_list. As for filter_user_list, this ONLY filters out users with conditions that are marked as applying to user lists. For example, group conditions are included but date conditions are not included. The returned SQL is a query that returns a list of user IDs. It does not include brackets, so you neeed to add these to make it into a subquery. You would normally use it in an SQL phrase like "WHERE u.id IN ($sql)". The SQL will be complex and may be slow. It uses named parameters (sorry, I know they are annoying, but it was unavoidable here). If there are no conditions, the returned result is array('', array()). Conditions do not need to check the viewhiddenactivities or viewhiddensections capabilities. These are handled by core_availability\info::get_user_list_sql. return: array Array with two elements: SQL subquery and parameters array param: bool $not True if this condition is applying in negative mode param: \core_availability\info $info Item we're checking param: bool $onlyactive If true, only returns active enrolments |
| unique_sql_parameter(array &$params, $value) X-Ref |
| Utility function for generating SQL parameters (because we can't use ? parameters because get_enrolled_sql has infected us with horrible named parameters). return: SQL code for the parameter, e.g. ':pr1234' param: array $params Params array (value will be added to this array) param: string|int $value Value |
