version = 2021052500 release version
requires= 2021052500 same than version
Why 20210525? (25th May 2021) ?
Because master is going to be Moodle 4.0, to be released
on November 2021. And, until then, we are going to have
a couple of "intermediate" releases:
- Moodle 3.10 to be released 9th November 2020. (2020110900)
This version will be using versions from today to 2020110900
(once it's released the YYYYMMDD part stops advancing).
- Moodle 3.11 to be released 10th May 2021. (2021051000)
This version will be using versions from 3.10 release to 2021051000
(once it's released the YYYYMMDD part stops advancing).
That means that all versions from today to 2021051000 are going
to be used by those 2 "intermediate" releases (3.10 and 3.11).
And we cannot use them in master, because it's forbidden to have
any overlapping of versions between branches (or different upgrade
paths will fail).
So, get that 2021051000, let's add it a couple of weeks to cover
the on-sync period (or a 2 weeks delay max!) and, the first version
that master can "own" in exclusive (without any overlap) is, exactly,
25th May 2021, hence our 20210525.
Both ldap or the DB can return information in a non-consistent
ordering leading to events to be generated in different order.
And current tests are, right now, assuming a given order.
Note this is a rare random, but it's happening, so better
fix it, see the issue for some more details.
So we just do the tests ordering immune, verifying that all the
expected events have been triggered and done. Irrespectively of their order.
The external database authentication plugin (auth_db) can update the
external database if mapped fields are set to Update external: On
update. This change adds error handling in case this update fails.
With that provider we'll be explicitly covering that any
pagesize and subcontexts search is returning results consistently
so the internal paging/servercontrols work as expected.
Starting with php74 the following functions are deprecated:
- ldap_control_paged_result()
- ldap_control_paged_result_response()
Starting with php73, ldap servercontrols were included. One of those
servercontrols, LDAP_CONTROL_PAGEDRESULTS, is the one in charge of
controlling paged results.
So, we are going to add some conditional code here:
1) if php < 7.3, use old paged result functions.
2) if php >= 7.3, switch to LDAP_CONTROL_PAGEDRESULTS servercontrol.
With a TODO about removing 1) in Moodle 4.1, once php73 becomes required.
This just deletes all the upgrade steps previous to 3.5.0. Some
small adjustments, like tweaking globals can also be applied
when needed.
Also includes an upgrade step to prevent upgrading from any
version < 2018051700 (v3.5.0) as anti-cheating measure.
Previous commits have removed/deprecated all the upgradelib functions
not used anymore in codebase. Deletion has been documented in corresponding
upgrade.txt files:
- upgrade_fix_block_instance_configuration()
- upgrade_theme_is_from_family(), upgrade_find_theme_location()
and linkcoursesectionsupgradescriptwasrun setting
- upgrade_block_positions
- upgrade_fix_config_auth_plugin_names()
and upgrade_fix_config_auth_plugin_defaults()
- format_xxx_upgrade_remove_numsections(), format_xxx_upgrade_hide_extra_sections()
and format_xxx_upgrade_add_empty_sections()
- filter_mathjaxloader_upgrade_cdn_cloudflare()
and filter_mathjaxloader_upgrade_mathjaxconfig_equal()
- get_assignments_with_rescaled_null_grades()
These have been kept because continue being used by restore:
- \core\task\refresh_mod_calendar_events_task
These functions were used only by deleted upgrade steps
so it's safe to proceed with straight deletion, considering
them internal. Deletion has been documented in corresponding
upgrade.txt files:
- upgrade_fix_config_auth_plugin_names()
- upgrade_fix_config_auth_plugin_defaults()
This basically does two things:
1. Updates all non-Facebook/Google/Microsoft issuers and sets their
'requireconfirmation' field to 1 so that future OAuth2 logins on these
issuers will always have an email confirmation sent to them.
2. Deletes the linked logins of users with non-Facebook/Google/Microsoft
OAuth2 issuers.
* set $idp['iconurl'] = null if no auth_logo
* lib/templates/loginform.mustache will skip NULL iconurls
* lib/ajax/service?info=tool_mobile_get_public_config will validate the NULL values
I did not think thought through if this new URL parameter would be a
potential security hole. The simple cop-out option is to make it only
work on Behat sites for now.
Significant string changes:
* moodleorghubname,core_admin and
sitemustberegistered,message_airnotifier - 'Moodle.net' changed to
'Moodle'
* registration_help,core_admin and registermoochtips,core_hub - removed
erroneous 'access to Moodle.net our course sharing platform'
* trackingtype_help,mod_forum and formnotavailable,core_grading and
showgrades_help,core and rolewarning_help,core_rating -
'Administration block' changed to 'Actions menu or admin block',
'navigation block' changed to 'navigation drawer or block'
