This class would belong more appropriately within the 'user' API
(core_user) instead of within the 'core' API, since it is
directly related to user data.
Since the class has only just been added to Moodle, now is a good
time to move it.
In all cases changes have been kept to a minimum while not making
the code completely horrible. For example, there are many instances
where it would probably be better to rewrite a query entirely, but
I have not done that (in order to reduce the risk of changes).
These function updates are in preparation for the participants_search
class, which will be used to support multiple values per filter when
filtering the participants page.
A new optional parameter $context has been added to the
core_group::groups_get_members_join() function.
Besides, some core_group methods now accept -1 (USERSWITHOUTHGROUP) for
the groupid field.
The function groups_get_user_groups is called too often both before rendering the page and after the page is rendered (using ajax).
The function was executing a query joining 3 tables in each call. The plementation of the function has now modified to store the
query result in a request cache.
Refactor similar SQL generation code from get_users_by_capability
and get_enrolled_uses to make get_with_capability_sql.
Modified files: accesslib.php, enrollib.php, grouplib.php, new tests.
* Upgrades existing data so that the groupmembersonly option is
replaced with equivalent data for the new availability API.
* Removes the database field and admin setting used for
groupmembersonly.
* Changes core modinfo library to remove/deprecate groupmembersonly
data and functions.
* Changes other core library files to remove groupmembersonly
references.
Includes deprecation of several functions, listed in lib/upgrade.txt.
When assignment is "Available for group members only" and no users with
mod/assign:submit role permision is enrolled (students),
groups_filter_users_by_course_module_visible is causing error (as $users
array is empty). The patch resolves the issue.
Add a function to the groups lib to filter a list of users down
to the ones who can see the module. Required because calling
groups_course_module_visible() for a list of users is too slow
and we shouldn't spread group logic outside of grouplib.php.
Using it in the assign grading table reduces DB queries from 6198/1 to 256/3.
This is 12secs down to 2.5secs.
Conflicts:
lib/db/upgrade.php
lib/phpunit/lib.php
version.php
Fixed:
lib/db/upgrade.php - duplicate course->sectioncache add code
lib/db/install.xml - cleanup needed because xmldb editor was not used
lib/phpunit/classes/util.php - cleanup $GROUPLIB_CACHE on test reset
There was a static cache inside course/lib.php. I need to access this
information in other places, so to avoid making two queries, I am
moving the cache into the groups_get_all_groupings function instead.
The current group in verified on each page which prevents problems when group settings are changed. The default group for course level is now using correct grouping id which solves problems when activity and course are using different grouping. The grouping is now displayed in group selector if user has access to all groups.
(reverse-merged from commit 0d1e49d46838f6916f93561866fdd83beaf24a0f) This change was causing fatal errors on the course level, I am going to fix it myself.
