Part of MDL-66074
This change modifies the return val for all of the grading functions to
allow them to add additional information.
This means that a grading service can suppress a Grade saved message if
there were no changes, for example.
This also adds a distinction between:
- Errored (Exception thrown in the WS call)
- Failed (Warning in the output of the WS call)
- Success (Grade actually saved)
- None of the above (No save, no fail, no change)
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.
