Group visibility was not taken into account when
generating SQL for getting enrolled users restricted
to a list of groups. This may have allowed users to
infer membership of groups they were not allowed to
see members of.
Right now the order of the groups returned by groups_get_user_groups()
is not fixed and, every DB, can return them in any order. While 99%
of times the order will be the creation one, depending of the RDBMS
decisions, they can be returned in any order.
This is specially noticeable with Oracle, but can affect to any DB.
And that makes some tests (expecting a given order) to fail.
This commit fixes the problem by making the order of the groups
deterministic, because that's the way we use to fix these problems.
Alternative is to relax the tests so only values are asserted by
using assertEqualsCanonicalizing().
These new settings are designed to enchance user privacy surrounding
groups. They allow groups to be configured so that users outside the
group cannot see the group, so that users in the group cannot see each
other, or so that users cannot see the group at all, even if they are in
it. This avoids issues where a group may be assigned based on sensitive
personal information (such as a person requiring special arrangements
due to a disability).
By default, groups are visible to all and available for participation in
activities, which maintains the current behaviour.
For performance, a new cache has been added to track the number of
groups on a course that are not visible to non-members. This allows us
to revert to the existing behaviour if the new features are not being
used at all on a course, and only apply the new visibility conditions if
they are.
Users who have the moodle/course:viewhiddengroups capability should be
concious of exposing hidden groups when showing their screen to other
users. The "Switch role to..." feature can be used to show a course page
on screen without exposing private availability conditions, for example.
The changes cover several specific areas:
* grouplib functions, which most code should use to get lists of groups
and members (this includes the participants page).
* Activities supporting group overrides will not allow overrides for
groups that are hidden from all users.
* Activities supporting separate/visible groups modes will only allow
groups with the new "participation" flag enabled to be selected.
* Group messaging will be disabled for groups where members cannot see
each other, or cannot see the group at all.
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.
