This class would belong more appropriately within the 'user' API
(core_user) instead of within the 'core' API, since it is
directly related to user data.
Since the class has only just been added to Moodle, now is a good
time to move it.
In all cases changes have been kept to a minimum while not making
the code completely horrible. For example, there are many instances
where it would probably be better to rewrite a query entirely, but
I have not done that (in order to reduce the risk of changes).
This just deletes all the upgrade steps previous to 3.6.0. Some
small adjustments, like tweaking globals can also be applied
when needed.
Also includes an upgrade step to prevent upgrading from any
version < 2018120300 (v3.6.0) as anti-cheating measure.
Note that in this case, there wasn't any case of upgradelib
functions being used, hence we haven't to deprecate/remove
anything in codebase. When there is such a need, that is done
in separate commits (one for each function) and documented here.
See MDL-65809 commits for an example removing/deprecating a
good number of functions.
The optional parameters of assertEquals() and assertNotEquals()
are deprecated in PHPUnit 8 (to be removed in PHPUnit 9):
- delta => use assertEqualsWithDelta()
- canonicalize => use assertEqualsCanonicalizing()
- ignoreCase => use assertEqualsIgnoringCase
- maxDepth => removed without replacement.
More info @ https://github.com/sebastianbergmann/phpunit/issues/3341
Initial search done with:
ag 'assert(Not)?Equals\(.*,.*,' --php
Then, running tests and fixing remaining cases.
All the setup/teardown/pre/post/conditions template methods
now are required to return void. This was warned with phpunit 7
and now is enforced.
At the same time, fix a few wrong function names,
provider data and param types, return statements...
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.
This CSS statement was an MS-only rule which was never accepted, and
which was abonded some time before IE 10. It has no effect in supported
browsers and can be safely replace with `opacity: [0.0-1.0]`.
With the Guest registration calling policyactions.js the [data-action="view"]
was having two click handlers set on the inital policy modal trgger.
With this commit we state what we want the click event to be set on.
If javascript is disabled, we don't need to open the menus at all. If it is enabled
we should use the custom step where possible.
In some tests (user profile) we have to use link_or_button because
the element that opens the menu will be a link or a button in different themes.
When accepting the policies via the sitepolicy handler, only compulsory
policies are to be marked as accepted. Optional policies will be left as
pending. Users must express their consent explicitly for them.
As a side product of the change, unit tests are added for the whole
handler class.
This adds support for optional policies to the user acceptance reports.
Distinguished are "Pending" acceptances (we did not hear yet) from
"Declined" (user did not agree). The status workflow updated to support
new transitions: pending -> declined and declined -> accepted.
There was an accessibility issue with the previous icons that we used
the same "checked" shape just in different colours for different
meanings. New icons added for the new statuses:
* partial - a warning icon for the overall status column that the user
has only some policies accepted, not all.
* pending - that we did not hear yet from the user - whcih is different
from a declined policy.
For optional policies, we provide a radio selector to let the user
choose the acceptance status on the consent page. For policies displayed
on their own page, we display a link to decline the policy.
The way how we pass the list of policy version ids to index.php has
changed so that we can now not only pass the list of ids, but also the
actual acceptance status (accepted / declined).
This method allows to quickly check if the given policy version is
marked as optional or compulsory. This will be needed in other places
such as permissions check.
The method now returns three-state logic. A bool value true/false is
returned if the user has accepted/rejected the policy, respectively. A
null value is returned if the user did not express their agreement in
either way yet.
This allows to distinguish between "rejected the policy" and "did not
say anything about it yet" cases.
Bas Brands