The API was incorrectly assuming that all uses of the API were for a
course, and that the instanceid of the communication instance was a
course id. These assumptions are both entirely wrong.
The API is intended to support a range of uses including use at the
site, user, and activity levels.
Furthermore, if a group were to be used, then the instanceid should be
of that group's id, and therefore the contextid would need to be fetched
or that group's course instead.
The only solution here is to add a new contextid field to the table, and
implement it all parts of the API.
During install/upgrade, caching is disabled. This change provides a
way to temporarily enable caching (using in-memory cache storage only)
within a specific function; caches are deleted afterwards.
Adding this to two locations improves install performance quite a lot.
Caching is not enabled during the parts of plugin installation that
can vary for individual plugins (install.php/upgrade.php) as these
might be relying on its absence, for example by making direct database
changes.
Adding new capabilities can be slow if they have permissions cloned
from an existing capability, and if there are many places in the
database where the existing capability was overridden.
This change optimises the clone-capability performance, approximately
halving the number of queries required.
Adding multiple capabilities was very slow because it clears and
rebuilds the capability cache after each one. This change makes it
clear the cache once after adding all capabilities, before adding
permissions to the archetype roles.
* 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.
