In PHP 8.2 and later, setting a value to an undeclared class property is
deprecated and emits a deprecation notice.
So we need to add missing class properties that still need to be declared.
The new entities encapsulate related data for easier re-use across
reports, and are also intended to replace similar columns/filters
from the current enrolment entity.
Default value of the $flag argument changed in PHP 8.1 from ENT_COMPAT to ENT_QUOTES | ENT_SUBSTITUTE
To ensure consistent behavior across different PHP version the second parameter is now required for the functions:
htmlspecialchars(), htmlentities(), htmlspecialchars_decode(), html_entity_decode() and get_html_translation_table()
Thanks to MDL-49398, we can separate the combined user session and role
definition cache clearing function into two separate functions. At the
same time, we want to identify and remove mark_dirty() calls that were
added for role definition changes but were incorrectly left behind.
Change highlights:
- Remove unnecessary mark_dirty() calls performed after
assign_capability(), unassign_capability(), delete_role(),
deleted contexts, brand new contexts
- Move role definition cache clear from the user-centric
accesslib_clear_all_caches() to the newly created,
role-dedicated accesslib_reset_role_cache()
Role name and description fields are currently not escaped when
exporting a role. This results in an unusable file when characters
such as ampersands are used in a name or description. Fix this by
using htmlspecialchars on both fields.
Signed-off-by: Nigel Cunningham <nigelc@catalyst-au.net>
action_icons should not be cached as they
have a unique id and if cache is used then
all icons will have same id.
Other solution is to replace id with some static
but it's not worth a cache for a page, so
removing cache
This is an extremely dangerous query, because it includes the user
table twice, along-side two other potentially large tables,
role_assignments and user_enrolments.
The solution is to rewrite the query so that:
1. The subquery is JOINed, not WHERE ... INed. Typically query
optimisers handle the JOIN case better.
2. Before the join was role-assignments <-> users <-> subquery.
That is, everything was linked to u.id.
Now the linking is role-assignments <-> subquery <-> users,
so the SELECT DISTINT eu1_u.id FROM {enrolled users} is central.
That seems to send a strong hint to the query optimiser about
a good order to execute the query.
