This commit will implement the base api for core
communication. This will include the room creation,
room membership, room access url and all associated
api and related interfaces.
Originally implemented as MDL-76702, MDL-76703 and MDL-76705.
Co-Authored-By: David Woloszyn <david.woloszyn@moodle.com>
Co-Authored-By: Safat Shahin <safat.shahin@moodle.com>
Move the fixed assignment removal upgrade code to the end of the upgrade
script as a new upgrade step. Already upgraded sites with mod_assignment
removed should just be able to rerun this without any issues.
The Assignment 2.2 activity module was disabled in 2012 but kept to
enable pre-2.2 backups to be restored and have the assignments
auto-converted to new assignments. After almost 10 years, it's time
to remove it from Moodle core.
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.
Note that, despite the commit message, this is not possible. Moodle
3.11.0 (and 3.10.0) were developed in parallel with Moodle 4.0, and
when they were released, the master branch had already diverged, so
the master branch does not contain the comment lines:
"// Automatically generated Moodle v3.11.0 release upgrade line"
And they are needed to know which parts of the upgrade are safe to delete.
So we only proceed to delete all those steps from lib/db/upgrade.php
which version is known to be < 2021051708 (v3.11.8), master ones will
be, always bigger than that. We don't touch plugin upgrade scripts
because they may have different versions, not 100% matching the
2021051708 rule, so there will be an excess of steps there.
Note this is not a big problem, just a few more steps will be skipped and
that's all. Whenever we bump the Moodle requirements again (to Moodle
4.0 or up), the lines will be back and we'll be able to safely remove
all the steps before them. See previous Moodle requirements issues as
example.
The upgrade steps deleted by this commit weren't using any stuff from
upgradelib, tasks..., so there isn't anything else to be removed but
the core steps themselves.
Also includes an upgrade step to prevent upgrading from any
version < 2021051708 (v3.11.8) as anti-cheating measure.
Pass correct parameter/type in field constructor (`XMLDB_NOTNULL`)
for consistency. This corrects the definition and preserves the
truthyness of the value that was incorrectly passed previously.
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.
Normal removal procedure:
- Remove the plugin completely from core.
- Document it in the webservices upgrade.txt file.
- Add a core upgrade step to proceed to remove any configuration
if the plugin has not been re-installed manually.
Plus:
- Remove a few remaining uses in the hub/sites registration scripts,
that were moved from xmlrpc to hand.made rest calls by MDL-31436
(Moodle 3.4.1 and up) and never removed then.
- Remove the php-xmlrpc extension as a recommendation in composer.
- Remove "xmlrpc" from various comments, trivial cleanup.
Note:
- While working on this MDL-76078 has been created about to
fix a serious design problem detected (it does not affect
functionality). That's out from this issue scope.
This allows admins to configure whether contact site support is
available to everyone, authenticated users, or nobody.
The behat testing checks linked and direct access for each setting,
as well as adding testing that the support page override works as
expected.
Previously, if a course module had already been graded, course module
completion linked to the course module would not update. This
commit adds the option to enable overriding the grade at the course
module competency level.
This ensures that if enabled and a user completes a module associated
with a competency, that competency will be graded appropriately.
For a long time, Moodle has had the feature to force the language
for a whole course. This change adds the same feature at activity
level.
The course-level feature was controlled by a capability
moodle/course:setforcedlanguage, and I decided to use the same
capability to control this feature. I think a new capability would be
overkill.
This just deletes all the upgrade steps previous to 3.9.0. Some
small adjustments, like tweaking globals can also be applied
when needed.
Also includes an upgrade step to prevent upgrading from any
version < 2020061500 (v3.9.0) as anti-cheating measure.
The next commits will proceed to deprecate / remove functions
that were exclusively (usually belonging to upgradelib) being
used by those, now removed, upgrade steps. This is the list
of code to remove and document in upgrade.txt files:
- upgrade_analytics_fix_contextids_defaults()
- upgrade_convert_hub_config_site_param_names()
- upgrade_rename_prediction_actions_useful_incorrectly_flagged()
- \mod_forum\task\refresh_forum_post_counts adhoc task.
And these is the code that has NOT been removed
because it may be needed later (no matter there aren't uses now):
- \core_search\manager::clean_up_non_existing_area(), used by
- \core\task\clean_up_deleted_search_area_task adhoc task
