When you download a file directly from a Moodle form submit button,
the submit button disables when you click it, but you remain on that
page so we need to re-enable the button.
This commit causes it to re-enable once the file download finishes,
setting a temporary cookie to indicate this to the JavaScript code.
It also adds a method to disable the system on a given form by
setting data-double-submit-protection="off".
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'
Significant string changes:
* direct:view,gradeimport_direct - wording corrected from 'CSV' to
'spreadsheet'
* limitanswers_help,mod_choice - additional wording added explaining how
the setting works with groups
* pluginname,customfield_text - 'Text field' plugin renamed to
'Short text'
By adding the "Search" aria label to a number of elements
any search of "Search" buttons, previously working in other
parts of the UI are not found anymore (because the hidden
ones are found before).
So, moving to click via xpath. Ideally we should be able to
find the target button in an easier, human readable way. But
there aren't many ids, names around to make it easier.
Query using the following fields for
\gradeimport_csv_load_data::check_user_exists() should be done in a
case-insensitive manner:
* email - As agreed in MDL-29315
* username - Although usernames can only be in lowercase during
registration, usernames are being handled in a case-insensitive
fashion when logging in. It makes sense to make check_user_exists()
consistent with this behaviour.
* We need to ensure that we are checking the correct user account.
Since email and idnumber are not unique fields, there's a chance that
multiple user records will match when querying for user data using
these fields. This might lead to a different user's grades being
inadvertently modified during grade import. In such a case, this
function needs to return a null userid.
If the grade types text or none are selected for an item or a category,
none of the 'grade display type' options will change the displayed
grade within the reports. Thus, we can disable the settings for grade
display type as well as the one for decimal places in this case.
3.7 (min PHP 7.1) requires 3.2 (first version supporting PHP 7.1)
This just deletes all the upgrade steps previous to 3.2.0. Some
small adjustments, like adding missing MOODLE_INTERNAL or tweaking
globals can also be applied when needed.
Also includes an upgrade step to prevent upgrading from any
version < 2016120500 (v3.2.0) as anti-cheating measure.
Next commit will get rid of/deprecate all the upgradelib functions
not used anymore in codebase. (note there isn't any this time).
