Search moodle.org's
Developer Documentation
Developer Documentation
- Bug fixes for general core bugs in 4.3.x will end 7 October 2024 (12 months).
- Bug fixes for security issues in 4.3.x will end 21 April 2025 (18 months).
- PHP version: minimum PHP 8.0.0 Note: minimum PHP version has increased since Moodle 4.1. PHP 8.2.x is supported too.
/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. 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 return: bool True if there was any change |
| 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). 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) return: bool True if there was any change |
| 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. 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 return: array Filtered version of input array |
| 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. 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 return: array Array with two elements: SQL subquery and parameters array |
| 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). param: array $params Params array (value will be added to this array) param: string|int $value Value return: SQL code for the parameter, e.g. ':pr1234' |
