The methods assertContains() and assertNotContains() now perform
strict (type and value) comparison, pretty much like assertSame()
does.
A couple of new assertContainsEquals() and assertNotContainsEquals()
methods have been created to provide old (non-strict) behavior, pretty
much like assertEquals() do.
Apart from replacing the calls needing a relaxed comparison to those
new methods, there are also a couple of alternative, about how to
fix this, depending of every case:
- If the test is making any array_values() conversion, then it's better
to remove that conversion and use assertArrayHasKey(), that is not
strict.
- Sometimes if may be also possible to, simply, cast the expectation
to the exact type coming in the array. I've not applied this technique
to any of the cases in core.
Link: https://github.com/sebastianbergmann/phpunit/issues/3426
In PHPUnit 9.1, the following regexp-related assertions
have been deprecated and there are new alternatives for
all them:
- assertRegExp() -> assertMatchesRegularExpression()
- assertNotRegExp() -> assertDoesNotMatchRegularExpression()
This is about to, simply, move all cases to the new alternatives.
Source: https://github.com/sebastianbergmann/phpunit/blob/9.1.0/ChangeLog-9.1.md
Regexp to find all them:
ag 'assertRegExp|assertNotRegExp' -li
Both assertContains() and assertNotContains() are deprecated in PHPUnit 8
for operations on strings. Also the optional case parameter is. All uses
must be changed to one of:
- assertStringContainsString()
- assertStringContainsStringIgnoringCase()
- assertStringNotContainsString()
- assertStringNotContainsStringIgnoringCase()
More info: https://github.com/sebastianbergmann/phpunit/issues/3422
Regexp to find all uses:
ag 'assert(Not)?Contains\('
When inherit is specified in the data registry it is stored as a
string and we cannot perform a strict comparison with it.
We should still compare strict comparison checks against null, or false,
but not for the NOTSET (0) or INHERIT values (-1).
Inheritance should behave such that all contexts inherit from their
parent context.
Prior to this fix, if the value was not set on a context, then it was
getting a default of 'Inherit', but instead of inheritting from the
parent context, it was inheritting from its parent context _level_ which
is just wrong.
This change rewrites the way in which expiry is calculated and addresses
a number of closely related issues:
Users can customise, and add blocks with data to, their dashboard. When
a user had done so, the user could be flagged for deletion, but the
blocks in their Dashboard were subject to the default block retention
policy. In addition there is no way to override the retention policy for
user blocks.
This change modifies the structure of the expiry mechanism:
- to consider any subcontext of the user context to be a part of the user
context during calculation. User child contexts are not the property
of the system, and should not be treated separately.
- the way in which the context expiry mechanism worked was to select
use a multiple different managers based solely on the context level.
Because of the use of user blocks, this proved to be unreliable as
blocks has been attributed purely to courses.
This has been changed to a single manager which is aware of hierarchy
and deletions as a whole.
- to prepare for upcoming work relating to more detailed expiry
mechanisms, a new expiry_info class is introduced and used to
merge the expiry of child contexts into a working in-memory view.
This changeset includes extensive unit tests.
Updated tests with latest statuses.
Added testing for request download expiry functionality and method.
Added assign_site_dpo within a parent class for unit tests.
Creating data requests
* Add capability check when creating data requests for another user.
Ad-hoc task that processes pending data requests
* Check if the requesting user has the capability to create the data
request for another user. Reject otherwise.
Ad-hoc task that processes approved data requests
* Validate that the requester can receive the notification about the
data request processing results.
* Do not send the confirmation link to DPOs/admins
* Disable tool by default.
* Add format columns for 'comments' and 'dpocomment' fields in
tool_dataprivacy_request table.
* Use data request exporter when sending email notification to DPO
This commit is composed of different issues, most of them under
MDL-61306:
- MDL-61888, MDL-61785, MDL-61830, MDL-61874, MDL-59720,
MDL-61486, MDL-61697, MDL-61798, MDL-61685, MDL-61682,
MDL-61684, MDL-61618, MDL-61681, MDL-61680, MDL-61487,
MDL-61499, MDL-61500, MDL-61362 and MDL-59718
Contributions to this patch by:
- Jun Pataleta
- David Monllao
- Andrew Nicols
- Adrian B. Greeve
- Jake Dallimore
- Sara Arjona
Eloy Lafuente (stronk7)