It used to be necessary to store the question number and question page
by adding them as random extra fields on the question object (but
I can no longer remember what that reason was). Now it is possible
to store this sensibly in the quiz_attempt object, which is much
cleaner, so do that.
This got added during the Moodle 2.0 files API conversion, but was
always part of a failed experiemnt, so should have been deleted
long ago. It was never actually used.
This commit replays, conditionally, all the upgrade steps from
MOODLE_19_STABLE to MOODLE_23_STABLE in the mod_book activity. That
guarentees that any site using the mod_book before landing to core,
no matter if it was the latest or an outdated one will upgrade
perfectly to the expected current version.
As a general rule, everytime one contrib plugin lands to core, its
complete upgrade code must be kept, at least until the core version
that introduced it, is out completely from the upgrade requirement
conditions.
In this case, with the missing upgrade code being added to 2.4, it
will be safe to delete the upgrade steps once 2.5 (or upwards) become
a requirement. Never always.
From now on, the evaluator's method get_settings_form() should return a
subclass of workshop_evaluation_settings_form. The evaluation subplugins
are expected to use the define_sub() method to add their own fields into
the base form, although they can override the main define() method, too.
The former interface workshop_evaluation has been refactored into a
superclass with abstract methods which seems to be more robust.
Oh, by the way, I'm in Perth - yay!
AMOS BEGIN
MOV [settings,workshopeval_best],[evaluationsettings,mod_workshop]
AMOS END
Teachers can now choose the actual grading evaluation method to use
during the grading evaluation phase. The workshopeval_best is still used
as the default one (this may be made configurable later, although there
is no big benefit of it).
Function add_mod_to_section() has very confusing arguments when object looks like record from
table course_modules but field ->section refers to relative section number (course_sections.section).
In table course_modules the field section refers to course_sections.id.
Also add_mod_to_section() does not update table course_modules and does not call rebuild_course_cache()
which developer can forget to do afterwards.
- Added function course_add_cm_to_section()
- In the core code add_mod_to_section() is replaced with course_add_cm_to_section()
- Function add_mod_to_section() is deprecated
This prevents a bug where the next student feedback will default to the values that
were on the last submitted form. This is a similar case to having multiple instances
of the same form on the same page - each one needs a unique identifier to distinguish
between them. In this case I include the $rownum which changes as you go to each student
in the list.
This will allow to keep assessable_submitted event object structure consistent
throughout the system, while particular modules could define own parameters
within params variable.
This module defines submission_editable parameter to reflect if user can edit
submission before assessment has been done.
