This adds the ability to to add comments to ip lists in moodle.
Currently, the configiplist textentry box does not allow the user to annotate
the IP addresses defined. For example, I'd like to be able to define:
192.168.1.1 # London office
10.1.1.1 # New york office
118.209.246.240 # My home IP
This would allow me to revisit this list after a few months, and remove
IP addresses that are no longer required - without having to manually confirm
each IP address
The standard password validation does some basic strength checks, but
there are a number of other ways to validate a password, such as
checking that it doesn't contain common words. Adding a plugin hook
here allows us to keep up with changes in best practice in this area
as it evolves over time.
If enabled $CFG->allowcohortthemes, then themes can be set at the cohort level.
This will affect all users with only one cohort or more than one but with the same theme.
The default theme order will be: course, category, session, user, cohort, site.
Also deprecated the following functions -
1. message_move_userfrom_unread2read - It is not necessary
for us to mark a message as read on user deletion.
2. message_get_blocked_users - Horrible logic used to
determine if a user is blocked via reference on some
randomly chosen 'isblocked' variable.
3. message_get_contacts - The same as above. This can be
done in a much nicer way.
4. message_mark_message_read - We want two functions to do
this to avoid confusing messages and notifications.
5. message_can_delete_message - This assumed the variable
$message contained the 'useridto' property, which
was present in the old table structure. We do not want
future usages where a query is done on the new table
and is simply passed as this won't contain this property.
6. message_delete_message - Same as above.
- Define sitepolicy handler manager class, base class and the core handler
- Allow to set a plugin as sitepolicyhandler that implements the sitepolicy API
- Modify web services to return information from the 3rd party handler instead of core if needed
The patch introduces a new site setting 'sitepolicyhandler' that can be
either empty or contain a plugin component name. If it is empty, the
site policy feature keeps working as before and the core keeps the
control over it.
If a plugin is specified, it is expected to implement the callback
'site_policy_handler' in its lib.php file. The callback should return a
URL to a script where the user can accept the site policies. The plugin
itself is responsible for setting the 'policyagreed' flag in the users
table. The callback may return an empty value, in which case the user
can continue using the site without being redirected.
The patch adds support for a new pre-config flag NO_SITEPOLICY_CHECK.
This constant should be defined and set to true if we should not check
the user's policyagreed status during the require_login().
This is for pages where the user actually accepts the site policies and
helps to avoid the redirect loop.
set_user_preference and unset_user_preference let you pass the user to
set preferences for as an id. Previously, if you passed $USER->id there,
those methods did not update the Cache in $USER, which was surprising,
and not easy to debug.
Now, we always update the preference cache in $USER if the preference is
being changed for the current user.
Andrew Nicols