In addition to adding in theme usage reports, there is also the
addition of an icon on the theme cards which takes you to the report.
This icon only appears for that theme if it has been used in any
overriding context.
Co-authored-by: Stevani Andolo <stevani.andolo@moodle.com>
Including in this commit:
- Added a new counter called attemptsavailable for ad-hoc task
- PHPUnit test for the new feature
Currently, the $CFG->linkcoursesections setting was only used
for the Classic theme, to let admins decide whether the section
names in the Navigation block would be linked or not.
Now that the course/section.php page has been created to display
the content of any single section, and a link to this section page
has been added from the main course page to help users to focus
on the section content, it has been decided to remove the setting
$CFG->linkcoursesections because it's not required anymore.
This adds indexes on the timecreated and timeread columns, which greatly
speeds up the queries used by \core\task\messaging_cleanup_task on large
sites.
This admin setting allows you to display a check anywhere in the admin
tree. It uses a webservice to execute the check, so the impact on the
admin tree performance is as low as possible.
Checks do not necessarily need to be registered in the plugins callback
to be shown here, allowing customisation of what is shown in the
settings versus the reports.
Set the web service functions core_calendar_get_action_events_by_timesort
and core_calendar_get_action_events_by_timesort to use read only
sessions. These functions can hold long session locks
and read-only sessions will prevent them blocking other requests.
Set the web service function core_message_send_instant_messages to use
read-only sessions. This function can take a few seconds to process if
it is sending messages to lots of users, and setting it to use read-only
sessions will prevent it from blocking other requests.
The API was incorrectly assuming that all uses of the API were for a
course, and that the instanceid of the communication instance was a
course id. These assumptions are both entirely wrong.
The API is intended to support a range of uses including use at the
site, user, and activity levels.
Furthermore, if a group were to be used, then the instanceid should be
of that group's id, and therefore the contextid would need to be fetched
or that group's course instead.
The only solution here is to add a new contextid field to the table, and
implement it all parts of the API.
David Woloszyn