As well as fixing the bug, I also rewrote the test to use
data providers, which should lead to more useful failure messages.
And, I moved the magic number we used as the float tolerence to
be a named constant.
* Introduce the "actionmenulinkclasses" block in the action_menu_link
template so other templates importing it can have the option to override
its classes.
* Have the action menu trigger template use the action menu link
template to reduce code duplication.
With the static function variable $instance, calls to
\action_menu_link::export_for_template() from its subclasses are stored
in different variables. This causes duplicate IDs when different
implementations of action menu links are rendered on the action menu
trigger/link template. (e.g. action_menu_link and
action_menu_link_secondary both rendered on the same page).
To make the incrementing uniform for the action_menu_link class and its
implementations, the $instance variable is moved out of the
export_to_template() method and is now made to a static class variable.
Links and normal text should have at least a colour contrast ratio
of 3:1. To achieve this, $body-color will be using the darker
shade of gray $gray-900 (#212529).
Links and normal text should have at least a colour contrast ratio
of 3:1. To achieve this, $body-color will be using the darker
shade of gray $gray-900 (#212529).
Darkened the fills of completion icons in order to meet the required
minimum contrast ratio of 3:1.
* Changed gray fills (#999) to #949494.
* Changed blue fills (#76A1F0) to #6393ee
* Changed green fills (#9C3) to #79a128
Thanks to Barbara Ramiro <barbara@moodle.com> for the help in
updating the SVG icons!
* Darkened the link and clickable icon colours inside coloured events.
* Added borders around event colour indicators inside the month-view of
the calendar for better contrast against the white background.
If a scheduled task which uses a 'R' field is picked, then the reset of
updated task times will not necessarily be correctly determined as the
randomisation is picked during reset.
This can lead to some random test failures.
Actively specifying a test which does not make use of the 'R' random
field time addresses this issue.
Before this change in a frozen context a user would be able to delete
their own comments.
After this change a user will only be able to delete their own comments
if they still have the capability to post new comments or the capability
to delete comments from any user.
Under parallel development, when something is worth being commented
in upgrade.txt notes, it will be applied to all the development branches
using the "earliest" one to be released. So, if something changes
in 3.10 (and also is applied to master), the upgrade.txt notes will
show 3.10 in both branches.
Of course, if something only goes to one dev branch (say master), then the
master version will be used in the notes (4.0 in this case).
