CAST() target types aren't very portable. Use DECIMAL which works
for MySQL and Pg.
DECIMAL does seem to be supported in Oracle - but the syntax seems
different. We may still need a compat function.
is_siteadmin checks a few key capabilities to suss out if the user is
an admin. The main virtue of the function is that it does not use
the accesslib infrastructure -- it reads directly from the DB, which
is useful for the 1.9 accesslib upgrade.
If we are passed an empty string for $order, still create valid
SQL. Some callers in 1.9 seem to not care about order, passing
an explicit ''. Shocking! ;-)
These references to the deprecated functions were erroring out. Remove
them.
Note however that other role related cleanups done as part of
MDL-10679 "improvement to context_rel table and load_user_capability()"
are kept.
We now populate the context.path only where it's empty,
this means that we take 0.15s instead of 0.6s. More importantly,
we avoid thrashing the DB's indexes pointlessly.
We also support Oracle and its dirty hack here.
And the function now has a $force parameter that can be used to
actually overwrite the paths/depths in case they've been corrupted.
get_assignable_roles() was calling user_can_assign() (cost of 1~2 DBq)
once-per-role. Instead, we can do a single DB query that answers
all our questions in one go.
On a Moodle w 8 roles defined, saves 19 DB queries for the course page
for teachers/admins.
NOTE NOTE NOTE! With this patch we drop the insane strip/escape bit.
Only the caller knows if this is for display on html or for other uses,
so we'll be true and not mangle the data.
A review of all callers in 1.8 shows no problem - the strings were being
strip/escaped already.
When querying capabilities of non-logged-in users, has_capability()
will now load accessdata for the subcontexts as needed.
Without this patch, below-the-course RAs and rdefs were ignored when
checking caps for a user different from $USER. I don't think it is
ever done in current moodle code, so the problem wasn't visible.
In any case - it's fixed ;-)
Both of them are dead code in 18_STABLE and HEAD. And if
role_add_lastaccess_entries() is ever used on a large site it will
hammer the DB to bits.
Remove before anyone is foolish enough to try it.
We had a 1s race condition where a user could get their rights loaded
at the exact time an admin is changing roles/caps and see the "old"
data. Or even see a half-updated view of the access controls.
Yuck.
So we fix the race condition backdating the dirtyness. Cheap, but
effective. And then we backdate it some more to cover for minor clock
flutter on clusters (you still need ntp however!).
has_capability() can handle the fake user that forum cron sets up
and will load the appropriate accessdata into $USER->access.
This makes forum cron work again. A test comparison between before
this patchseries yields:
With 1 forum post, sent total 24 times
- Before 11 000 DB queries (approx)
- After 506 DB queries
With 6 forum posts, sent a total of 452 times
- Before 47 876 DB queries
- After 8 256 DB queries
There is a very high variability, but we are going from 100-500
queries per sent email to 18-21 queries per sent email. The
variability probably stems from 2 of the 6 posts being in a 200-user
forum.
Still huge - by the time we are sending the email, we should know
everything we need to know about the user, the forum/thread/post and
the form. The average should be well below 1 DB query per email sent!
Costs next to nothing according to testing, and allows us to walk
the categories very cheaply. We'll need this in get_my_courses()...
What a cheapskates I am...
If you are a teacher in course X, you have at least
teacher-in-X + defaultloggedinuser-sitewide. So in the
course you'll have techer+defaultloggedinuser.
We try to mimic that in switchrole.
Thanks to Petr for pointing me to a similar fix in CVS.
Probably related: MDL-10945
We had quite a bit of leftover rdef and ra mangling.
Be more thorough and clear it up.
While at it, make load_user_accessdata() and load_all_capabilities()
more consistent.
There are some exceptions when checking for caps that are inherited
from the default role. Move the check into has_cap_fad() and stop
mangling the data we put in $ad[rdef].
We now also set $ad[dr] to record default roles added.
This will later allow us to share rdef across many users in $ACCESS.
Affects:
load_user_accessdata()
has_cap_fad()
While at it, document has_cap_fad() a bit.
When setting things up for the guest user, the RA entry in accessdata
was not multi-enrol-friendly. Must have glossed it over in the
multi-enrol rework.
The name for new data structure holding access control data
is "accessdata". And we have a new moniker "fad", short for
"from accessdata".
So
- has_cap_fromsess() -> has_cap_fad()
- access_inaccessdata() -> path_inaccessdata()
- aggr_roles_fromsess() -> aggr_roles_fad()
- $sess -> $ad
- $access -> $ad
Consistency, save typing, shorter codelines...
With the new accesslib, moving courses and categories has a major
impact on enrolments and unenrolments.
At _least_ we need to signal accesslib that it has happened. So here
is context_moved() for exactly that.
Open to refactoring later into something along the lines of
- move_course()
- move_category()
However, at this stage the most important of those two: move_course()
does not fit very well with the code in course/edit. So keep it simple
for now.
... and it populates the context cache too.
Unfortunately, it needs an INSERT followed by an UPDATE. Other than
a stored procedure, I don't know how to deal with this better.
(We could save the SELECT though! that's a thought...)
OTOH, we are getting so much mileage out of the path field
that it's probably a hit we have to take in the chin and move on.
Callers _must_ do their homework before calling create_context().
This allows us to save 2/3 queries per call (!!!).
As it stands, callers are all in accesslib anyway.
Manually enrolling and unenrolling self, and other users should
transparently set the context dirty. So walk all callers to
role_assign() and role_unassign() and mark the context dirty
where appropriate.
OTOH, most automated-backend enrol/unenrol mechanisms should not.
The backend lookups that happen when you login are well covered
by the login/enrolment process, and don't need to be marked dirty.
If accessinfo is stale, we need to reload it without losing
out "interesting" state -- transparently for the end user.
That means preserving active role switches, loginas (site and course
level), etc. The logic for that is encapsulated in
reload_all_capabilities().
Also affected:
- has_capability() which now calls reload_all_capabilities()
- role_switch() - minor tidyup
