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.
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).
- Fixed reference to non-existent column 'timeread'.
- Fixed alignment issues.
- Fixed inconsistencies between upgrade.php and install.xml.
- Cleaned unit tests of unnecessary DB calls.
- Renamed 'get_does_conversation_area_enabled' to
'is_conversation_area_enabled' and moved to api.php.
- Replaced "$mform->elementExists('enablemessaging')"
check with a capability check.
- Removed the change of [] to array() in unrelated to upgrade code.
- Updated conversation 'timemodified' field when updating name.
- Bumped version based on latest master.
The new recordset support for Postgres requires transactions and
will cause errors if recordsets are not closed correctly. This
commit fixes problems that were identified during unit tests, and
via some basic code analysis, across all core code. Most of these
are incorrect usage of recordset (forgetting to close them).
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.
* 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.
1) Tidied up conditional check and put additional variable on new line.
2) Prevented change of the default behaviour for 'groups_get_potential_members()'.
3) Added another behat test.
MDL-45991 groups: Auto-create groups with ungrouped users only
When using auto-create groups, sometimes it is needed to only create
groups with users that are not already inside a course group. This
patch creates a checkbox that will ignore users that are in already
existing groups. It alters the groups_get_potential_members function so
that the eligible users are retrieved entirely though sql.
This combines the following changes:
* Event for group member added
* Event for group member removed
* Event for group created
* Event for grouping created
* Event for group updated
* Event for grouping updated
* Event for group deleted
* Event for grouping deleted
* Adding tests for deleting functions
* Bulk remove of members uses low-level API
The reason for this is that a bulk event has no value from a logging
perspective as it is not granular. So now, the API is a bit slower,
but the information the events contain makes sense, beside this is
not (and should not be) used very often.
The reason why the events_trigger_legacy() is kept is because we
cannot create a new event for this, as we don't encourage developers
to created bulk events, for the reasons mentioned above.
I removed the call that gets the user record from the function
groups_remove_member() as it was not required and only appeared
to check if the user existed. It appears to be safe not to do
this check as nothing would fail down the line.
* Bulk unassign of groupings uses low-level API
As the previous commit, we keep the legacy event for now as it would
be wrong to create a new event to replace it.
Also, the code has been changed to call the low-level API to unassign
groups from groupins, even though at the moment there are no
events for that function.
* Bulk deletion of groups uses low-level API
Again, we keep the legacy event because replacing it would force
us to create a new event that does not make sense. See MDL-41312.
* Bulk deleting of groupings uses low-level API
* Asserting legacy event name in unit tests
* Minor SQL query and code improvements
GD PHP extension is now required. Add-ons need to remove $CFG->gdversion tests. The worst case regression is that add-on will think GD is not available.
This patch includes following changes and new features:
* Group sync in enrol_cohort plugin.
* Option for editing of role in existing cohort sync instance.
* Group memberships are now restored after enrolments.
* New enrol method for restore of protected group membership.
* New component callback 'restore_group_member' for restore of general plugin group membership.
* New component callback 'restore_role_assignment' for restore of general plugin role assignments.
* Implemented group membership protection in enrolment UI.
* Other minor fixes and cleanup.
Notes:
* The YUI base enrolment page is not reimplemented yet - see MDL-35618.
This commit coverts everything in the codebase to use the new
users_order_by_sql function when sorting lists of users. More details in
the bug.
Note that this does not change places where users are displayed in a
sortable table, and the sort order comes from the table.
