Details
Bug
Description
Right now, when displaying the course/report/log there is one function in charge of calculating the selector form. it's the print_mnet_log_selector_form() function.
One the fields in that selector form is list of users in the given course. For SITEID that list can cause memory problems, due to the number of records returned by the get_site_users() function (and potentially in courses by the get_course_users() ) function.
The selector form includes code to prevent the list of users to be rendered if there are more than COURSE_MAX_USERS_PER_DROPDOWN (1000) users but that doesn't really helps in big sites because the program breaks before checking that.
Issue Links
| This issue has been marked as being related by: | ||||
| MDL-29803 | "Site administration ► Reports ► Logs" gives "Fatal error: Allowed memory size of 134217728 bytes exhausted" |
|
|
|
Activity
Resolving as fixed. The 1-4 steps above have been implemented in 19_STABLE (HEAD was really simpler) B-).
Ciao 
The proposal to fix this is about to do this:
1) Add two new params (limitfrom, limitnum) to the get_site_users()
2) Add two new params (limitfrom, limitnum) to the get_course_users() (used by 1)
3) OPTIONAL: Add two new params (limitfrom, limitnum) to the get_group_users() (to have the three functions on sync)
4) Use those params in get_users() and get_users_by_capability() that already have support for them. Nothing to change in those 2 core functions.
5) Pass as limitnum this: COURSE_MAX_USERS_PER_DROPDOWN +1 (i.e. 1001 right now).
6) That way, the functions will return up to 1001 records (that doesn't cause any memory problem) and we'll can then easily check and decide to show or no the list of users.
Those two params will default to '' so limits won't be affected in the rest of calls to those functions. NP at all.
Easy to fix, and safe IMO. Please vote. My +1 is here. One more required. Ciao