This has been generated running the following Sniffs, all
them part of the Moodle's CodeSniffer standard:
- PSR12.Functions.ReturnTypeDeclaration
- PSR12.Functions.NullableTypeDeclaration
- moodle.Methods.MethodDeclarationSpacing
- Squiz.Whitespace.ScopeKeywordSpacing
All them are, exclusively, about correct spacing, so the changes
are, all them, only white space changes.
Only exceptions to the above are 3 changes what were setting the
return type in a new line, and, when that happens, the closing
parenthesis (bracket) has to go to the same line than the colon.
Introduces some changes to the exising _extend_settings_navigation()
methods that utilize the global $PAGE object. In order to accomodate
the changes done for the secondary navigation for single activity
courses, the methods that extend the settings navigation can no longer
rely on the $PAGE object, instead the more reliabe way to obtain this
infomation is through the get_page() method from settings_navigation
class.
This class would belong more appropriately within the 'user' API
(core_user) instead of within the 'core' API, since it is
directly related to user data.
Since the class has only just been added to Moodle, now is a good
time to move it.
In all cases changes have been kept to a minimum while not making
the code completely horrible. For example, there are many instances
where it would probably be better to rewrite a query entirely, but
I have not done that (in order to reduce the risk of changes).
Applying filters on an activity module description when using it as a
new calendar event's description is bad m'kay? We need to store the raw
text and apply the filters only when we actually display the text. That
way, filters (such as multi-language content) may actually fully work
and we do not initialise the theme and output machinery.
Additionally, we need to explicitly set the format of the description
text to HTML (because we have converted it to it already). Otherwise it
defaults to the current user's preferred editor format.
This is still a pragmatic hot-fix solution. The proper solution would be
to pass the raw text, format and embedded files.
When some activities are manually completed by students, some are still showing in students' timeline.
This commit fix that for module assign,chat,choice,feedback,lesson,quiz,scorm and workshop.
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 allows the teacher to define what students are supposed to submit
(online text and/or attachment) and if the given submission part is
required or optional.
There was a bug with serving the files from the areas instructauthors,
instructreviewers and conclusion. These three areas should not use the
itemid in the plugininfo URLs. But they did use 0 as the itemid which
broke the file previews when browsing via server files repository.
The first part of the patch fixes all relevant calls to
file_rewrite_pluginfile_urls() so that null is now properly used instead
of zero.
The second part of the fix is that we no longer delete the first $args
element in the workshop_pluginfile() function - the itemid is not
supposed to appear there now.
The last part of the patch is that instead of repeating the same code
block copy&pasted for each file area in workshop_pluginfile(), we now
have a single block covering them all.
Huong Nguyen