Preserve existing `enhance` method return of jQuery style promises to
allow calling code to continue relying on that (e.g. when calling old
style `.done` and `.fail`).
Co-authored-by: Andrew Nicols <andrew@nicols.co.uk>
* Make sure that we respect the fullnamedisplay and alternativefullnameformat
parameters to decide on the initials for a given user
* Add further tests
Co-authored-by: Tatsunori Uchino <tats.u@live.jp>
When bulk-updating course module visibility, set_coursemodule_visibily
was triggering a partial cache purge and rebuild for each course module.
This potentially led to 2 cache sets each requiring a lock to be
acquired and released per course module, plus any other cache updates
for other changes to the course in the same request.
This adds a new $rebuildcache paramter to the
set_coursemodule_visibilty, which is true by default to retain the
existing behaviour. If set false, it will skip doing the partial purge
and rebuild for that course module, and it is up to the calling code to
ensure the cache is updated as requried.
To assist with this, there is a new
course_modinfo::purge_course_module_cache_multiple() method, which
allows multiple course modules to be purged from the cache in a single
cache set.
Basically the changes imply that:
- For some tests that are using reflection, we need to ensure
that the backup controller is passed.
- And, whenever used explicitly in tests, it has to be destroyed.
(note that this leaves out tests running get_package(), because
that method now instantiates and destroys the controller by itself.
only tests that get a controller need to destroy it).
- Move from some old functions to the new ones introduced in the issue.
Group visibility was not taken into account when
generating SQL for getting enrolled users restricted
to a list of groups. This may have allowed users to
infer membership of groups they were not allowed to
see members of.
In some places we prevented cache poisoning, in others we did not. We
also did not place any restriction on the minimum value for a revision.
This change introduces a new set of functions for configonly endpoints
which validates the revision numbers passed in. If the revision is
either too old, or too new, it is rejected and the file content is not
cached. The content is still served, but caching headers are not sent,
and any local storage caching is prevented.
The current time is used as the maximum version, with 60 seconds added
to allow for any clock skew between cluster nodes. Previously some
locations used one hour, but there should never be such a large clock
skew on a correctly configured system.
Co-authored-by: Andrew Nicols <andrew@nicols.co.uk>
- Switch use PARAM_TEXT instead of PARAM_URL for resource URL
- Added noreferrer to the Go to MoodleNet drafts button, to avoid the risks associated with opening in
_blank without removing access to the referrer and opener
This covers the 2 new functions with unit tests:
- xhprof_topo_sort()
- reduce_run_data()
Note that the example graph used in the provider is the
one shown in the issue to explain the reduction procedure.
* Makes it possible to safely call acquire_lock so that it throws an
exception instead of returning false if it can't get a lock (which
most existing uses assumed it already does).
* Fix some omissions from the requirelockingbeforewrite option (it
now checks on delete).
* Modinfo uses a versioned cache, so it is not necessary to delete
items, only increase the version. (Provided we keep track of
cacherev carefully...)
The external test file URL concerns itself only with HTTP_USER_AGENT
matching, not sending response headers, which can differ according to
HTTP protocol in use by the endpoint (1.1 vs 2).
Given the returned response code itself is irrelevant to the testcase,
there's not much benefit to asserting it and risking random failures.
