Adds an extra import section alongside the existing export in the
calendar views. Allows the user to import from either a file or a
URL as a subscription, with an optional polling interval of hourly,
daily, weekly, monthly, or annually. This subscription may be added
to the user, group, global or course calendars. These subscriptions
are tracked in a separate database table, and an extra column added
to the events table to relate them to the subscription. The event
uuid field is also expanded to allow for the RFC-2445 UID property.
Subscriptions are listed on the calendar view page, and can be
added and removed, manually polled, and the polling interval
adjusted. Subscription events are updated on cron.
This adds cron code which looks for question previews that have not been
touched for more than 24 hours, and deletes them.
We try to delete previews immediately. For example if the user clicks
start again, then we immediately delete their previous preview. However,
we can't do that if they just close the preview window. Hence we need
some cron code to clean up old preview that have got left lying around.
Normally, this code will not have much to do, so it will be very fast,
so we can afford to run it every cron.
This has been implemented in such a way that in future it will be easy
to add other cron code to the question bank.
Sadly, to make this work on MySQL, we require a horrible hack in the
already hacky delete_usage_records_for_mysql function.
Rather than overloading the $CFG->bloglevel setting which had a
confusing UI in the appearance subsystem.
In order to achieve this we modify take the defaults from the existing
bloglevel setting and set that for $CFG->enableblogs. Note that in order
to prevent a bad default settings from being set we also set
$CFG->bloglevel to a valid 'enabled' setting.
There is still some code that ignores delete_user() and instead hacks the user table directly, skip the borked user records for now when sending new passwords.
Because of a flaw in the logic, lastnotifyfailure was not set unless
there was a failure. This means that after 1 hour of no failures, the
function would execute every cron cycle, which has a pretty high cost
on large sites.
This method accepts all detected changes in cron-based fetch and picks
those the site admins want to be informed about (based on the maturity
level etc).
* Support for old non-standard cron for quiz reports dropped. (Standard
cron support was added in 2.2
* Cron support added for qbehaviour, qformat and quizacces plugins.
* qtypes were already supported in the standard way.
Auth and enrol is moved to the top because other plugin types depend on accurate user list and enrolments. Passwords and failed login messages are generated during every cron execution. Contexts are build properly in each execution. Fixed deleting of unconfirmed users. And minor phpdocs and comments improvements.
- Adds support for course report cron
- Moves existing admin report cron support to end of cron function
- Adds new core API get_plugin_list_with_function
note: default shipping course and admin reports do not use cron
function, this is only to support plugins.
