* Make the ordering of the message and the close button logical on
the DOM.
* Hide the times HTML entity
* Add sr-only label on the close button for non-sighted users
* Add tooltip on the close button sighted users
* With all the notification templates being the same except for the
class, I created a base notification template (core/notification_base)
that alert notifications just override. This avoids code duplication
and can make maintenance simpler.
Given that custom reports can now have defined pagesize properties, we
need to preserve that value in the table filterset so that it's always
available after AJAX requests.
- Replace all individual calls to add all columns, filters and
conditions on the cohorts datasource with the new
method add_all_from_entities().
- Replace all individual calls to add all columns, filters and
conditions on the courses datasource with the new
method add_all_from_entities().
- Replace all individual calls to add all columns, filters and
conditions on the users datasource with the new
method add_all_from_entity().
Without this index, a full table scan / table level locking occurs when
logging out of Moodle. This can result in slow performance in a busy
Moodle site.
Applied the following changes to various testcase classes:
- Namespaced with component[\level2-API]
- Moved to level2-API subdirectory when required.
- Fixed incorrect use statements with leading backslash.
- Remove file phpdoc block
- Remove MOODLE_INTERNAL if not needed.
- Changed code to point to global scope when needed.
- Fix some relative paths and comments here and there.
- All them passing individually.
- Complete runs passing too.
Special mention to:
- Moved to the level2 "privacy" namespace:
- \mod_assign\privacy\feedback_legacy_polyfill_test
- \mod_assign\privacy\submission_legacy_polyfill_test
- Moved to the level2 "task" namespace:
- \core_message\task\migrate_message_data_test
- \ltiservice_gradebookservices\task\cleanup_test
- \message_email\task\send_email_test
- \mod_lti\task\clean_access_tokens_test
- \mod_workshop\task\cron_task_test
- Moved to the level2 "event" namespace:
- \core_h5p\event\deleted_test
- \core_h5p\event\viewed_test
- Renamed to a better name:
- backup_forum_activity_task_test.php (missing "task")
Applied the following changes to various testcase classes:
- Namespaced with component[\level2-API]
- Moved to level2-API subdirectory when required.
- Fixed incorrect use statements with leading backslash.
- Remove file phpdoc block
- Remove MOODLE_INTERNAL if not needed.
- Changed code to point to global scope when needed.
- Fix some relative paths and comments here and there.
- All them passing individually.
- Complete runs passing too.
Special mention to:
- Some fixtures, initially defined in the test files have been
moved to new files in fixtures subdirectory, leaving the unit
test files clearer:
- moodle2_course_format_test.php
- Rename wrong named test:
- baseoptiogroup_test = baseoptigroup_test
Adds a new install script for the BBB module and a new upgrade step.
The BBB module now will be disabled by default for new installations
and also it will be disabled for the existing sites that use the
default BBB server configuration. Admistrators will be required to
confirm the acceptance of the related DPA prior to (re)enabling the
plugin once again.
Adds a note in the BBB general settings page to raise awareness about
the legal obligations related to the data processing agreement with the
service provider which is currently configured.
Implements a function for the 'pre_enable_plugin_actions' callback.
When the default BBB server settings are used while the administrator
attempts to enable the BBB plugin, the function will prevent this
action and trigger a dynamic form requesting the admin to conifrm
their acceptance of the related data processing agreement. The process
of enabling the plugin will continue as usual in cases where the
admin has already confirmed the acceptance of the dpa or a different
BBB server configuration is used other than the default.
Adds a callback xxx_pre_enable_plugin_actions in admin/modules.php
which plugins can use to force additional actions before enabling the
plugin. The return value (bool) from the plugin callback method
specifies whether the process of enabling the plugin should continue
after the added actions or not.
