When working against external services it can be advantageous to not
have automated tasks all hit the service at the exact same time from
many different installations.
This change allows the use of 'R' in hour/minute fields of the scheduled
task definition so a task will be installed with a 'random' hour/minute
value for these sort of occasions.
Note that the task will be installed in the database with a defined
time, this simply randomises the time chosen when loading from the
definiton.
Added property 'visible' for cohorts. Unsetting it hides the cohort from users in the course.
AMOS BEGIN
CPY [visible,core_moodle],[visible,core_cohort]
AMOS END
* Upgrades existing data so that the groupmembersonly option is
replaced with equivalent data for the new availability API.
* Removes the database field and admin setting used for
groupmembersonly.
* Changes core modinfo library to remove/deprecate groupmembersonly
data and functions.
* Changes other core library files to remove groupmembersonly
references.
Includes deprecation of several functions, listed in lib/upgrade.txt.
Creates two new functions that make it easier to get cm_info
objects (both in modinfolib.php):
get_course_and_cm($cmid) - intended for use e.g. in modules;
efficiently loads $course and $cm (normally saves 1 query).
cm_info::from_mixed($cm) - for use in back-end API where we
are not sure whether a $cm is a real cm_info or a stdClass.
On some pages full user data is not stored before user_created/
user_updated event is triggred. So giving option to trigger that
manually, so it can be triggred after all data is saved
Changes core code to use new API instead of the old one when
checking user access to activities and sections.
Includes changes to other libraries that are necessary after
adding the availability system and removing old conditional tables
etc.
As a precursor to deprecating M.util.show_confirm, this deprecates the
callback argment to the confirm_action class.
This is not currently used anywhere in core, and it's use leads to use of
eval in Javascript.
This locking system is designed to be used everywhere requiring
locking in Moodle. Each use of the locking system can be configured
to use a different type of locking (or the same type with a different
configuration).
The first supported lock types are memcache, memcached, file (flock),
db (specific handlers for pg, mysql and mariadb).
