The enabled state of a plugin is a tri-state value (boolean or
null). We should be consistent with elsewhere by only considering
boolean false as an actually disabled plugin.
See also cdcb53a1 for similar change in task management.
When defining settings that are used by scheduled tasks,
it is also useful, or even needed, to know the status
of that scheduled task to have the whole big picture of
that part of the system.
Based on the admin_setting_description, this new setting
reports its name, its status, a link to the configuration.
When adding a new setting of this type, the user can add
an extra description field to complete the whole meaning.
The `core\plugininfo\base::is_enabled()` uses three-state logic for its
return value. It can return null as a valid value as per its
documentation. We need to test for the explicit false value in this
case.
To make the attached Behat test able to identify the table, the caption
is added. It seems to be helpful for all users so I leave it displayed
without using the accesshide mechanism.
In the table that lists the scheduled tasks:
1. There are badges to show which components are disabled.
2. The plugin name (e.g. auth_ldap) is shown as well as the
human-readable name (e.g. LDAP server).
3. Where a time column has a non-default value, it is highlighted
and the default is shown.
4. If the fail-delay is non-zero, the cell is highlighted.
4. If you just interacted with a task (looked at or edited the settings,
did Run now, or cleared the fail delay) that row is highlighted,
and scrolled into view when the page loads.
To support this, some of the methods for loading the default tasks
have been extended with an optional argument to leave 'R' as 'R'
rather than replacing with a random number.
Also, mixed into this commit are a bunch of coding style improvements.
Sorry I did not separate them out, but ultimately this makes the
Moodle code better.
Some hosting providers have a requirement to prevent users making
modifications to the configuration of scheduled tasks as doing so may have
a negative impact not only on their own site, but also on the performance
of other sites (depending on host configuration). For example, if the
statistics or automated backup tasks were run every minute, this could have
a negative impact for other users).
Centralise management of all types of cron tasks with registration, scheduling,
parallel task conflicts(blocking) and running once off tasks, all using an
administration screen.
This is a combination of several issues:
MDL-25502: Added "black magic" task allocator for cron
MDL-25503: Add step to cron to run all scheduled tasks
MDL-25504 cron: Refactor to use scheduler
MDL-25505: Add an admin interface to schedule tasks via cron.
MDL-25507: Add support for adhoc tasks.
Huong Nguyen