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.
Added two new buttons to the group page to bulk enable or disable the
selected groups messaging settings.
Supporting Javascript modules were also added to disable/enable the
buttons depending on the groups selected in the picker.
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.
Create new entities for exposing report data on course groups and
groupings, joining to existing course/user entities to provide data
for the reportbuilder editor.
Passing parameters to implode() in reverse order is deprecated, use
implode($glue, $parts) instead of implode($parts, $glue).
This commit corresponds to phpunit and manual detections, core files.
The get_contexts_for_userid method should not return contexts for all group memberships.
It should only return the contexts in where there is manual group
membership.
This issue is part of the MDL-62560 Epic.
* Fix coalesce on postgres.
* The edit icon's alt shows the HTML entities causing
* enrol/tests/behat/add_to_group.feature Contains a '@doit' tag which I assume is there from testing.
* group/classes/output/user_groups_editable.php
** Missing MOODLE_INTERNAL check.
** Unused variables context_system and moodle_exception.
** The PHPDocs for the constructors are wrong.
** export_for_template() returns an array, not stdClass (according to parent docs).
** Change moodle_exception to coding_exception at the beginning.
* group/lib.php
** Missing docs for core_group_inplace_editable().
* user/classes/participants_table.php
** The docs for the class variables $groups, $course and $context need a '\' beforehand as they are in a namespace.
** I would prefer $this->context = $context; and $this->groups = ... to be done at the end of the constructor with the other class variable assignments.
** You could get rid of the class variable courseid if we are setting course and use $this->course->id instead.
** The function col_groups has @param \stdclass $row but it should be $data
* lib/amd/src/form-autocomplete.js and lib/amd/src/inplace_editable.js
** Some issues here CiBot has pointed out.
* lib/classes/output/inplace_editable.php
** @see should be on a new line.
