Search moodle.org's
Developer Documentation

See Release Notes
Long Term Support Release

  • Bug fixes for general core bugs in 4.1.x will end 13 November 2023 (12 months).
  • Bug fixes for security issues in 4.1.x will end 10 November 2025 (36 months).
  • PHP version: minimum PHP 7.4.0 Note: minimum PHP version has increased since Moodle 4.0. PHP 8.0.x is supported too.

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


Class: tree_node  - X-Ref

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'