The mod_lti css rule .path-mod-lti .message conflicts with text
alignment in chats in message an can be removed. The last occurrence
of the css class "message" was deleted from the mod_lti code in 2011
with 036e84c38913630ec5fe48e3ad6f230f1aa32253 (see MDL-30354).
Signed-off-by: Daniel Ziegenberg <daniel@ziegenberg.at>
These are the only cases 100% safe to apply the renaming of the
testcase class names to match the file names.
All other cases are not safe, because they are missing namespace
and may enter into name conflicts. Adding namespaces is not as
simple as imagined because it implies to, also, add a good number
of modifications to core. See the issue for more details.
* Add local function to access subsets of proxies and types direct from DB.
* Add local function to access count of proxies and types direct from DB.
* Add new external function to get both proxies and types with pagination.
* Add new external function to get count of proxies and types.
* Implement pagination using page factory in JS.
* Added unit tests to cover new external functions.
* Add mod_lti behat generators and tests.
* Show first and last button in paging bar.
* Created helper class to assist with new functions.
A similar approach was followed @ MDL-67935, although the
case doesn't seem to be the same.
In any case, it's curious that all local execution are
100% passing and only CIs fail so often. Just guessing if,
maybe, there is some Chrome version factor around (we
are running older, sticky, versions @ CIs.
Without this, people can craft URLs that other users might use not realising
what they do - and as a XSS vulnerability, it could do any number of things the
clicking-user has access to do on the site.
Change-Id: I82adc71e8706d8929011b4b24523d5b62b8ccea1
* When a label is passed to an (advanced) checkbox and no text
was provided, the label will be displayed on the right of the the
checkbox element. So there's no point in passing an empty string for
the label just to render the text to the right of the checkbox.
This just deletes all the upgrade steps previous to 3.6.0. Some
small adjustments, like tweaking globals can also be applied
when needed.
Also includes an upgrade step to prevent upgrading from any
version < 2018120300 (v3.6.0) as anti-cheating measure.
Note that in this case, there wasn't any case of upgradelib
functions being used, hence we haven't to deprecate/remove
anything in codebase. When there is such a need, that is done
in separate commits (one for each function) and documented here.
See MDL-65809 commits for an example removing/deprecating a
good number of functions.
