version = 2021052500 release version
requires= 2021052500 same than version
Why 20210525? (25th May 2021) ?
Because master is going to be Moodle 4.0, to be released
on November 2021. And, until then, we are going to have
a couple of "intermediate" releases:
- Moodle 3.10 to be released 9th November 2020. (2020110900)
This version will be using versions from today to 2020110900
(once it's released the YYYYMMDD part stops advancing).
- Moodle 3.11 to be released 10th May 2021. (2021051000)
This version will be using versions from 3.10 release to 2021051000
(once it's released the YYYYMMDD part stops advancing).
That means that all versions from today to 2021051000 are going
to be used by those 2 "intermediate" releases (3.10 and 3.11).
And we cannot use them in master, because it's forbidden to have
any overlapping of versions between branches (or different upgrade
paths will fail).
So, get that 2021051000, let's add it a couple of weeks to cover
the on-sync period (or a 2 weeks delay max!) and, the first version
that master can "own" in exclusive (without any overlap) is, exactly,
25th May 2021, hence our 20210525.
Also removed the scope attribute from the mini-calendar table
because according to https://www.w3.org/TR/WCAG20-TECHS/H63.html
it was not needed:
Note 1: For simple tables that have the headers in the first row
or column then it is sufficient to simply use the TH elements without
scope.
Before this change in most cases the queries generated by the API
would not be able to use an index as the subquery would use
conditions that coulde not be satisfied by a signle index.
By changing it to use UNIONs the database will be able to use an
appropriate index for each query in most cases.
Note this fixes the unit tests. Still the calendar API itself
should be able to manage this cases, both casting (int) or
being stricter about what's allowed there (param hinting).
But that falls out from this issue and the code that introduced
the failures, so the pure unit-test fix has been applied.
When calling the calendar_get_allowed_event_types function with
no course id, it is supposed to return true if you have the
relevant permissions in any course.
For users who have the managegroupentries permission, this was not
the case - even though it works correctly if you call the function
with a supplied course id.
This change makes behaviour with and without a supplied course id
consistent.
