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.
Some extra options have been added to the activitychoosertabmode setting, to let
admins decide when to display the Recommended tab.
Apart from that, one of these values have be set as default value for this setting,
as suggested by the UX/PX teams. So the Starter and Full presets have been updated
too with the new values.
In 4.0- version each time the course page is loaded the file handlers
are calculate din the backend and injected directly into JS using a json
encapsulation. With this new webservice the handlers can be obtained
directly from the frontend when needed.
I have opted not to go through any deprecation process for this as there
is not really much we can do about it anyway. There is no loss of
functionality - just a change of where things are served from.
The Yahoo! CDN was only used for http connections as it did not
officially support SSL, and it is not guaranteed to continue existing in
the future since YUI has been deprecated for a number of years now.
Right now we have the information only in docs:
- https://docs.moodle.org/dev/Core_APIs
- https://moodledev.io/docs/apis
And, in fact, we are crawling those pages to get the information
from various tools (moodlecheck, CiBoT...). Obviously, that's far
from ideal, the source only has the current list of APIs, and
there isn't much information there but the names.
So we are moving the source of information to be in core, so it
can be modified between branches, and contains richer information:
- The component the API belongs to, usually a subsystem or core.
- If the API can be used as level 2 namespace.
- If the API can be used as level 2 namespace out from its component.
Note that all that information has NO USES right now in core (and maybe
never will), but tools/checkers will benefit enormously by having that
information at hand, so we can check for namespaces, categories and
other bits way better.
Also, once we have this, the APIs dev documents linked above, surely
can be improved by being automatically generated and include all the
meta-information available.
It also includes a very basic json schema validating the basis. It can
be tried online @ https://www.jsonschemavalidator.net , or any other
tool. PHP requires extra libraries to be able to perform the validation.
Covered with unit tests, both api-related functions and structure validation.
