Memory usage was still high for long userlists. Use recordsets
to manage memory growth.
Note that we are still collecting a long long HTML table in memory
before we print it, so the footprint of the html itself is bit of an
issue.
With this patch, we fetch participants contexts in the main search
query. This cuts 1DBq per participant for the display.
Might fix MDL-11222 'global teacher viewing participants issues' where
we are getting OOM'd with many users.
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.
The SQL query that would fetch rdefs not associated with any ra was
not being executed. Duh! For example, a user with a teacher RA sitewide
would never be affected by a role override at the category
level, because it was not being loaded into accessdata.
get_user_access_bycontext() was narrowing down too much the rdefs it
was fetching. With this patch, it now correctly retrieves the rdefs for
new roles assigned in lower contexts, and also correctly retrieves
rdefs present in the course context (fixing MDL-11220).
This also means that we now do the job in 2 DB queries (instead of 3),
and we move a bit more data, but those rows are actually needed ;-)
Showing the calendar block was causing 2 DB queries per course the
user is enrolled in. Instead, use the data available in the array that
is passed as a parameter, and spare the DB a ton of needless traffic.
Fixes MDL-11221 Calendar not using context stuff from get_my_courses
Author: Martin Dougiamas
Very last caller to rebuild_context_rel() and any XX_context_rel()
function. move_category() already takes care of calling
context_moved(), which does the required context.path maintenance.
Addresses MDL-11219
Prevent calls to has_capability() in build_navigation() from messing
with upgrades.
Most calls to has_capability() in weblib should be moved to the callers.
Fix a thinko in a variable assignment that prevented us from grabbing
the correct roles as managers. Addresses Yu's report at
MDL-11182 admin shows up as teacher.
The initial implementation of has_cap_fad() just added the permission
values regardless of the locality of the context. This patch adds
support (read: fixes bug) for the "local context wins" rule.
Additionally, it removes a related bug where we were exiting early
if we found a CAP_PROHIBIT, ignoring the $doanything flag.
get_my_courses() now defaults to a much leaner dataset, but accepts an
array of "additional" fields we want. So ask nicely for the summary,
so that we can print_course() later with it.
New categories need a context immediately, and for top-level
categories, they also need to taint the "root" context to trigger
a reload of $USER->access.
This fixes problems with creation of initial courses(MDL-11178),
duplicate misc categories, etc.
Turns out class.t3lib_cs.php depends on class.t3lib_div.php. Will drop
the two commits before we go into HEAD.
This reverts commit 5768bf6fb4dfa334dc81a80d26111904c4d13abd.
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.
$PAGE->edit_course_allowed() has been reworked and is faster/smarter
than editcourseallowed(). It can also be made more specific on a
per-page-type basis.
Can't find it documented anywhere, but applicable_formats() is only
ever called as a class method, so it cannot say $this. Instead, say
block_admin_tree::has_admin_caps().
The largest of the 2 typo3 libs we ship in Moodle is never used. So
don't even parse it.
This takes Moodle's "default homepage" from 1.8MB to 1.6MB of PHP.
Tiny, but every bit helps...
If MDL_PERFINC is defined, we now print to errorlog a listing
of the files included, their size, and then a total size.
The total size isn't the most important metric, though it does give us
a good idea of how much PHP the PHP engine is parsing for us. The main
cost is still in the seeks involved.
Even when using precompilers -- our best-case scenario -- each include
or require forces at least 2 stat()s to compare timestamps in the php
file vs the precompiled file. If the working set fits in buffers we are
fine, but our 60+ stat() calls per page is quite a bit.
Dan Poltawski said:
> Previously users with different permissions could have granular
> access to the admin menu for the items they have access to, so
> limiting to only users with moodle/site:config would break that.
> Although I agree that that menu is slowww to render and needs
> fixing. Perhaps permissions for the various elements could be
> gathered and checked first
This commit addresses the problem checking for all the caps that are
mentioned by code in /admin (according to grep, at least). Some light
testing with the "moodle/user:create" seems to work properly.
This burdens us with maintaining the list in has_admin_caps() -- less
than ideal, but easier than rewriting /admin.
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.
The accesslib cleanups aren't needed every 5. Also, add
build_context_path() and instructions on how to run it
as build_context_path(true) to force a path rebuild.
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.
There is something _weird_ about the table setup on this page
and I cannot figure it out. This change "fixes" it in that
FF stops complaining.
However, the fix looks very broken to me.
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.
- The code uses the system context a lot. Declare
$sysctx at the top and use it.
- If the category has a context property, use it
(saves 1 DB query per category displayed)
The DB costs of this page in editing mode are
- ~100 DB queries for fix_course_sortorder()
- ~50 DB queries for the categories listing
If we rewrite both to lose the recursion, we could resolve the
page in perhaps 5 DBq.
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.