All lib_test and locallib_test classes:
- Namespaced with component (and API whenever makes sense).
- Fixed incorrect use statements with leading backslash.
- Changed code to point to global scope when needed or add new uses.
- All them passing individually.
- Complete runs passing too.
Special mention to tests under login/tests:
1) The core_login component doesn't exist.
2) But login/tests are allowed because there is a suite pointing to it (phpunit.xml).
3) So, the only possible namespace for them is "core".
4) And to avoid problems with other core testcases (under lib/tests)
they have been renamed to have login_xxxx as prefix.
As far as now all them have correct privacy level2 namespace:
- Move them to "privacy" subdir.
- Rename the files to "provider_test.php", this includes old
privacy_test.php and privacy_provider_test.php files
- Rename the testcase to provider_test too (to match file name)
Also, change some relative paths and comments to point to new
locations.
All privacy_test and privacy_provider_test classes:
- Namespaced with component\privacy.
- Fixed incorrect use statements with leading backslash.
- Changed code to point to global scope when needed.
- Renamed a few files to make all be privacy_test or privacy_provider_test.php
- All them passing individually.
- Complete runs passing too.
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
