In PHP 8.2 and later, setting a value to an undeclared class property is
deprecated and emits a deprecation notice.
So we need to add missing class properties that still need to be declared.
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 commit addresses a race condition when showing the message drawer
and opening the settings page from the Message preferences page.
In that situation, the message/edit.php page calls the
message_drawer_helper.showSettings function, which publishes a request
to show the drawer.
In some conditions (notably faster machines, or after MDL-66107) this
event is fired before the message_drawer.init has listened to it.
The solution here is to delay firing of the event until the drawer
announces itself as ready.
This ensures that the event is subscribed to before it is fired.
The OR conditions in the WHERE clause prevented the query from
effectively filtering the messages related to the user quickly, this
change helps gets around this by allowing the database to limit
the rows in the messages table it needs to scan significantly.
