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.
* Add a $deprecatedcapabilities variable to deal with deprecated
capabilities
Change-Id: I14f44d331e8a1c4bd9abe9566c78d911c0205583
Co-authored-by: Mark Johnson <mark.johnson@catalyst-eu.net>
Modifies the 'core_course_get_enrolled_users_by_cmid' webservice and
the generic js methods that call this webservice and enables defining
whether the ws should only return the active users or all enrolled
users in the course.
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 code was used only by deleted upgrade steps so it's safe
to proceed with straight deletion, considering it internal.
Deletion has been documented in corresponding upgrade.txt files:
- upgrade_analytics_fix_contextids_defaults()
- upgrade_convert_hub_config_site_param_names()
- upgrade_rename_prediction_actions_useful_incorrectly_flagged()
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
As well as storing 1/0 to indicate hidden state, they are also used
to store a timestamp indicating hidden until date. Increasing field
size allows these values to be stored without triggering exceptions.
