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.
