* Add a $deprecatedcapabilities variable to deal with deprecated
capabilities
Change-Id: I14f44d331e8a1c4bd9abe9566c78d911c0205583
Co-authored-by: Mark Johnson <mark.johnson@catalyst-eu.net>
On some larger sites, processing the navigation with format_string will
habitually load all the contexts for navigation which can take 400+ DB
queries. Explicitly tying all those format_string calls to the system
context reduces this overhead to a single DB query that probably has
already been run on the page previously.
Co-authored-by: Peter Burnett <peterburnett@catalyst-au.net>
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 patch adds better core support for copying courses.
There is now a simplified and dedicated UI for copying
courses. This can be accessed from the course context
menu or course management screens.
All backups are done asynchronously and there can be multiple
copies of a course in flight at once.
In fact, rather than fix the old logic, I noticed that the correct
logic was already implemented in get_users_by_capability. So, I
refactored to extract the working version into a function, which it
turns out can have exactly the same API as get_with_capability_join,
which was convenient.
Adds new API support within search engines for optional methods to
delete data for courses and contexts, and implements this for the
two core search plugins (simpledb and solr).
The new API is automatically called when courses or contexts are
deleted. When a whole course is deleted, it only sends the course
delete rather than sending 1,000 separate context deletions as
each activity/block is deleted.
This was originalyl intended as a performance improvement, but the
parent is already stored, and once calculated the value of locked is
already returned.
This chagne adds support for a new feature known as Context Locking.
This allows a context to be locked, thereby removing all write
capabilities for all users (including admin) for that context, and all
child contexts.
This change ensures that all capabilities at module context level are
shown within a module, only filtering out those which belong to another
module or the subplugins of another module.
This has the effect that module-level capabilities are included
providing they relate to
- the module being queried
- any subplugin of that module
- any capability at module level which does not belong to another module
or its subplugin
- any other explicitly included capability
This allows permissions to be defined on a capability at a context
level.
Whenever the role_capabilities table is changed, we need to remember
to clear the cache for the role(s) being modified. This is far simpler
when all of those changes happen in a single file, i.e. accesslib.php,
allowing other parts of the application to use the public functions
without requiring knowledge of the cache internals.
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()
Shamim Rezaie