When no roles mention the capability, get_context_users_bycap() breaks
badly. This trivial patch does a sanity check before jumping into the
SQL shark-pool...
MDL-13160
MDL-13000 Adding support for developers to add their own capabilities to local/db/access.php
This relies on a local/ language pack as well for the capability names.
Notes on implementation are in lib/locallib.php
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.
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
This fixes the handling of default roles as "tie breakers" for lower
RAs in conflict, and simplifies the code a lot.
The main loop in get_user_by_capability() runs a simpler state machine
that just collects role assignments (roleid and depth), and handles
pagination.
The complex part of the state machine has moved to
has_capability_from_rarc() which will walk the data structures
collected by get_user_by_capability() for each user.
Having all the complex state handling of $hascap there makes things a
lot easier for pagination and general sanity of
get_user_by_capability().
MDL-12452
we don't deal with RAs in the main SELECT -- we deal with _capabilities_
which is an entirely different matter ;-) -- so push the ra.hidden check
into the subselect.
Also, remove ra.hidden from the default list of fields. Hopefully no
callers are using ra.hidden -- if they are, they should be calling
something else, as this function deals with capabilities. So we might
need an audit of callers, to check that noone is expecting ra.hidden
to be there.
MDL-12452
