As the admin_category::add() method now checks for the third parameter,
couple of typos were detected in the code. Additional parameters passed
to the add() method were probably a mistake, a relict or a typo.
Note that the typo in admin/tool/unsuproles/settings.php had actually
significant impact on the functionality as the array with required
capabilities was not actually passed to the admin_externalpage
constructor as intended.
The patch introduces a new optional parameter of the add() method for
all classes implementing the parentable_part_of_admin_tree interface.
Currently we have only one class admin_category implementing this
interface. If some third party code implements this interface too, they
will get an error and will have to fix the add() method signature.
However, the chance that such third party code exists is considered
pretty low.
This works on the expectation that the returned array from readdata()
is opaque and will be fed directly into readquestions() since
filebase is different per file and needs to be set up appropriately
before each parse.
The $sql used in these methods may contain multiple parts glued
together by the UNION operator. Simply appending the ORDER BY statement
to the end of the query does not work in all DBs (failure reported at
Oracle). Following the pattern already applied in MDL-30051, we wrap the
SQL into yet another SELECT statement and perform ordering there.
Credit goes to Sara Cenni for suggesting the fix.
The input_manager now accepts colons (:) in TYPE_PATH options, but only
in cases where the colon is used as a part of Windows drive labels, as
in C:\apache.
For statslib tests was enough to require cronlib.php as
far as all the tests there are using ob-capture / output
expectations, so the new function does not bork anything.
For pluginlib tests finally the use was deleted because
it's a part of cron not interesting (should be always "cheap")
and to keep it there we should be adding a bunch of output
expectations under some cases, for practically nothing.
course, cohort, enrol, role, groups and forum used to use hard-coded
MAX_USERS_PER_PAGE=100 for rendering user list. This has been converted
to $CFG->maxusersperpage.
