It turned out that behat's "I should see ..." does not work for buttons
rendered as `<input>` elements so this assertion worked only in Boost
where the button is rendered as `<button>` but not in Clean.
But we do not really need this check here. All we need is to make sure
that the form has been saved successfully. For which, checking for the
text on the page is enough.
p.s. Another mistake of mine to not double-check behat on both standard
themes. Sigh ...
This Behat scenario was not failing only because it actually relied on
the bug in the wrongly set accepted_types for submission attachments.
Now that the previous commit has fixed that bug, this scenario started
to fail correctly.
We need to do the same trick here as we are doing in the latter
scenario: we first upload a valid file to bypass the upload repository
checks, and rename it before submitting the form. That allows us to see
that the invalid file is caught finally.
p.s. It was a silly mistake of mine. I should had been wondering why
the same procedure worked for one field and not for the other. I would
spot the bug with wrong accepted_types earlier.
It was a copy&paste mistake that the accepted_types option for the
submission attachments used the value configured for overall feedback
attachments.
Credit goes to Marina Glancy for catching this during testing.
Since the refactoring towards using the filepicker for file and picture
fields there are several variables, which are set but never read. Thus,
I removed them.
When a file or picture field was added with existing records, these
records could not be saved, since the draft area was not created
properly.
Co-authored-by: Jérôme Mouneyrac <mouneyrac>
All 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_mimetypes()
- upgrade_fix_missing_root_folders_draft()
- upgrade_minmaxgrade() and upgrade_minmaxgradestepignored setting
- upgrade_course_tags()
- atto_equation_update_librarygroup4_setting()
- mod_lti_upgrade_custom_separator()
These have been kept because continue being used by restore:
- upgrade_group_members_only()
- upgrade_extra_credit_weightoverride()
- upgrade_calculated_grade_items()
This just deletes all the upgrade steps previous to 3.0.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 < 2015111600 (v3.0.0) as anti-cheating measure.
Next commit will get rid of/deprecate all the upgradelib functions
not used anymore in codebase.
Based on work by Tim Lock <tim.lock@blackboard.com>
While upgrading to Moodle 2.8 or above it is possible for it to fail if
the site has multiple graded attempts for a user without an associated
submission record. This caused the upgrade to violate the databases
unique key rules.
This same issue could apply to a backup that was created of an
assignment that had this issue, when it is restored into Moodle 2.8 or
later.
This change adds the attempt number from the grade table into the query
that is inserting the new submission record (thanks to Tim). It also
moves the insert query before the latest flag is set on submission
records to ensure that only one has it, without this it is possible that
multiple submission records would be marked as the latest after an
upgrade or restore.
The element copes well with the legacy syntax - just extensions, no
dots. So the upgrade step is not actually necessary here. The element
has in-built validation so there is no need to validate it explicitly
here again.
