In the view pages I changed the container function call to a simple "echo 'div ...'" to avoid the custom_corners container overhead and page oddity.
In weblib I added "clearfix" handling to the function "print_box_start($classes ...". "clearfix" is handed over to the containing divs. This is a hack, but I didn't know how to handle it without rewriting too much areas.
Also made the course request category more robust, as breakage would
incur if $CFG->defaultrequestcategory didn't exist as a category.
merged from MOODLE_19_STABLE
print_error()'s third parameter is the URL we jump to (defaults to
$CFG->wwwroot if not set) when we click the 'Continue' button, not the message
string parameter object.
Forward ported from MOODLE_18_STABLE
This was a Google Summer of Code 2007 Project.
This introduces two new files, admin/cliupgrader.php and lib/installlib.php.
It also introduces a new PEAR library, Console_GetOpt. I have recieved permission from the upstream author to include this in GPL Moodle (essentially dual license it) - notes in lib/pear.
Most stuff that outputs html during install gets suppressed by the use of a constant.
Run the script like php admin/cliupgrade.php --help for info.
Note that this all uses strings from install/ rather than lang, so I have updated stringnames.txt accordingly and they'll all be broken until the cronjob that generates them runs.
With some subselect-outer-join poison-pill magic, when the we don't
want doanything users, we remove the roles that would grant such
dubious status.
Just a flick of the SQL muscle, actually.
After calling get_users_by_capability(), use
sort_by_roleassignment_authority() to mimic what older versions of
Moodle did.
Affects: get_teacher(), get_course_teachers()
MDL-12452
This will help us bridge the gap from olden-style order-by
user_teachers.id. From the phpdoc...
Will re-sort a $users results array (from get_users_by_capability(), usually)
based on a sorting policy. This is to support the odd practice of
sorting teachers by 'authority', where authority was "lowest id of the role
assignment".
Will execute 1 database query. Only suitable for small numbers of users, as it
uses an u.id IN() clause.
Notes about the sorting criteria.
As a default, we cannot rely on role.sortorder because then
admins/coursecreators will always win. That is why the sane
rule "is locality matters most", with sortorder as 2nd
consideration.
If you want role.sortorder, use the 'sortorder' policy, and
name explicitly what roles you want to cover. It's probably
a good idea to see what roles have the capabilities you want
(array_diff() them against roiles that have 'can-do-anything'
to weed out admin-ish roles. Or fetch a list of roles from
variables like $CFG->coursemanagers .
MDL-12452
get_users_by_capability() can no longer refer to properties of role
assignments or roles, as the capability aggregate is indirect.
Fixes:
get_teacher() - though the results will be poor, as we cannot provide
role.sortorder reliably
(used mainly by mod/workshop)
get_course_teachers() - which seems broken for a lot of situations as
its default parameters still refer to old tables.
MDL-12452
get_admins() and get_admin() were counting on
get_users_by_capability() returning a role-assignment id to pick the
"primary" admin account. With the get_users_by_capability() rewrite,
we no longer have an RA id to clearly blame for the capability.
So, rewrite get_admins() based on the known-good SQL used in
is_siteadmin().
MDL-12452