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
Oracle does not accept column labels in the GROUP BY section -
get_logs_usercourse() and get_logs_userday() were computing the
day/hours column and using it in the GROUP BY. The compatible fix
is to reproduce the same computation in the GROUP BY section.
Credit for the fix goes to Dennis Rochford <Dennis.Rochford@usq.edu.au>.
make_context_subobj() was not providing a contextlevel property, and
no callers fetched the field. This comes from its humble origins where
it was only ever called for course objects. These days it's used in
many other situations, so this patch DTRT and
- fixes make_context_subobj() expect a cxtlevel and turn it into
contextlevel
- fixes all callers (accesslib, datalib) to provide it
Having no roles set as coursemanager is a valid setting.
get_courses_wmanagers() should not produce invalid SQL on it...
actually, it should not even try to get the course managers.
With this patch, get_categories() now adds a nice context
sub-object to the returned object, which means callers can
save DB traffic.
It now also supports "deep" retrievals, which means we can
rewrite the course categories display pages to avoid
costly recursion.
Don't update fields unnecessarily. Cuts 3 DB queries per category
on course/index page (45 in a 15 category setup).
fix_course_sortorder() should be fixed to avoid recursion.
For an efficient print_courses() we need to grab in a constant number
of queries...
- course data
- "course manager" role assignments
- user records for the coursemanagers' fullname()
So here we do it in 2 DB queries. The 2nd one (grabbing RAs and user
records) can be expensive if we are dealing with a large number of
courses.
Which we shouldn't - When the number of courses is large the course
listing doesn't come this way anyway...
Reworked course_parent_visible() to always return in a constant
number of db queries (2 worst case) regardless of nesting depth.
The rewritten version has a small cache, but if you are going to
walk many courses, it's still 1~2 DB queries per category seen,
so the right thing to do is to check it in the caller, as seen
in get_my_courses().
Reworked gmc to perform the course visibility checks. These are
very cheap if $CFG->allowvisiblecoursesinhiddencategories is true.
However, where we have to enforce category visibility, it adds a bit
of work. In simple terms, it adds a DB query to read all the categories,
and extra checks to make sure we are doing the right thing WRT
- course visibility vs the permission to see hidden courses
- category visibility vs the permission to see hidden categories
and still do it quickly.
stronk7