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()
problem 1: links to blocks permissions changes were missing in boost
problem 2: when modifying link from dashboard user is returned to profile ('returnurl' passed but not respected)
problem 3: link to check permissions missing from category management page
fix: instead of respecting both 'return' and 'returnurl' parameter use only 'returnurl'
fix: use 'popup' layout when modifying permissions for a block
dirname() is a slow function compared with __DIR__ and using
'/../'. Moodle has a large number of legacy files that are included
each time a page loads and is not able to use an autoloader as it is
functional code. This allows those required includes to perform as
best as possible in this situation.
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.
