When updating/deleting a section/module, the system now only
invalidate of the element (section/module), not the whole course cache
Also, the system now only recalculate the cache for element (section/module)
if necessary, not the whole course cache
Move module/section purging to course_modinfo:
+ course_modinfo::purge_course_section_cache_by_id was created to purge section by id
+ course_modinfo::purge_course_section_cache_by_number was created to purge section by number
+ course_modinfo::purge_course_module_cache was created to purge module
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.
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.
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.
Previously when a repeating chat was updating the calendar
it would only update the timestart column. It needs to also
update the timesort column to display correctly on the new
overview.
format_text cannot be called on the whole input text, but must be
called on user-supplied text that will be output into chats. This
means it cannot simply be called in one place, but must instead be
called on the relevant parts of text once commands have been matched.
