When grades are deleted, it needs to know the context so any files
in the gradebook can be deleted. This means module delete_instance
functions must delete the grade_item before they delete the module record.
Grades that have been hidden will appear in the outline/complete
report - even if the user is a student.
The modules that have been fixed are:
* mod_assign
* mod_data
* mod_forum
* mod_glossary
* mod_lesson
* mod_scorm
* mod_workshop
The capabilities changed ('contextlevel' => CONTEXT_COURSE changed to
'contextlevel' => CONTEXT_MODULE) are:
* moodle/site:accessallgroups
* moodle/site:viewfullnames
* moodle/site:trustcontent
* moodle/site:viewuseridentity
This list came from reviewing the _get_extra_capabilities functions in
all core activities. They were all somewhat inconsistent, but I think it
makes sense that these capabilities are consistently overridable in all
activities. E.g. moodle/site:accessallgroups affects conditional
availability even if there is no other user of groups, and
moodle/site:viewuseridentity and moodle/site:viewfullnames affect the
logs report, if nothing else.
As a result of this, several _get_extra_capabilities functions are no
longer needed, and all the rest have been simplified.
This commit reviews all continue uses in core happening within a
loop / switch / case hierarchy. This does not cover:
- Changes to libraries. Will be handled in another issue / commit.
- Uses out from loops, will be reviewed by other commit.
The policy followed has been:
- When possible, take rid of the continue.
- When clearly the intention was to jump to next element in loop
change to continue 2
- When it was not clear, keep old behavior switching to break, no
matter how weird the behavior may be.
It was decided to roll only configuration dates and any date related to user content
such as 'timecreated' , 'timemodified' etc should not be rolled forward.
Added required entries text field to the completion criteria area.
This field accepts a number.
If the legacy Entries required field has a value greater than 0 it will
be displayed and editable. For new instances this field will not be displayed.
Some templates can legitimately contain invalid HTML (e.g. mismatched tags)
because the templates operate in pairs.
In these instances we should not use an editor because the nature of the
editor (content editable) means that the browser automatically corrects all
HTML supplied to it, thus breaking the template entirely.
Therefore we need to disable HTML editors for some templates, and do so in
a way tied to the instance of the activity, rather than to a specific user.
This patch adds a new 'config' field, with matching setters and getters, to
allow such per-instance values to be stored.
Andrew Nicols