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.
Due to Moodle 2.7 and Moodle 3.4 not having a common compatible php version
between them to upgrade from Moodle 3.4 from Moodle 2.7 you'll need to upgrade
to a higher version first or upgrade php at the same time as upgrade,
this encourages the former.
* Introduce a new php compatible library which can be used
early in execution, without Moodle dependencies
* Use it where we previously had hardcoded checks
This was originally suggested in MDL-39007.
Removed the concat to generate the uniqueid field for the popup
notifications data. The concat can't be used directly in the SQL because
the syntax changes between databases. The sql_concat helper can't be
used because it assumes all values are database columns (which they
aren't in this case).
Instead I've just removed the uniqueid field because it isn't required
for the union all to work and the field isn't being used by anything.
This should fixed the compatibility issues between databases.
The OR clause in these queries used different sets of columns to select
userid which meant that the indexes that included user id could not be
used.
This change splits the query so that each individual part can use one of
the indexes that includes a userid which speeds them up considerably.
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.
While working on the filetypes element validation, I realized we did not
cover the case of selecting 'Any file type'. So the value '*' was
falsely reported as unknown file type.
This patch introduces support for an optional method provided by the
form element classes to validate the submitted values implicitly -
without the need to have the rule explicitly added via the form
definition.
I am aware this should ideally be added to the HTML_QuickForm_element
parent class. But I wanted to avoid modification of that third party
library and keep the change in the moodleform layer only.
This is a pragmatic (read: hacky) solution of the problem that
Behat/Mink is unable to locate the input field within the filetypes
group. I've spent a while trying to figure out how to make it work. On
the road, I've discovered that our situation with labels of mform group
elements is a bit messy. And generally there seems to be no easy way how
to use the group's label to identify one particular input field in the
group.
In this case, we use mform group but in fact there is a single input
field within the group. Mink does not locate the group itself as an
input field and throws ElementNotFoundException. So reusing the group's
label as a hidden label for the input makes sense from certain
perspective.
The potential drawback (unconfirmed) is that screen readers might read
the same label text twice. But only one of them is associated with the
actual input field so chances are they would ignore the group's one,
like Mink does.
