- Modified SQL in get_data() to get the activity completion of all course modules without calling get_fast_modinfo() to reduce the DB queries.
- Building activity completion cache for the whole course in one time instead of building the cache for each course module by passing $wholecourse = true to get_data()
This adds the requirement for activities supporting custom completion to
specify the order all completion conditions should be displayed for that
activity. It also implements the sorting that takes place.
This commits adds a fallback for plugins which does not have
custom_completion implementation.
For those cases, it will search for {modulename}_get_completion_state
callback in the plugin and call get_overall_completion() method in
cm_completion_details class to get the overall completion state for
a course module and user.
Since cm_info::customdata can be of any type, we need to cast it to an
array first before checking for custom completion rules. Otherwise,
an exception can be thrown (e.g. customdata has been set as an stdClass)
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.
core_completion_get_activities_completion_status was not returning
completion information for users with the teacher role only (when it
wasn’t a role allowed to track completion).
The core_completion_get_activities_completion_status was getting the
progress for all users on the course called, and then discarding all
the records but one.
This change ensures that only progress for the user we are interested in
is retrieved from the database.
This has a side benefit of removing a full table scan from the query
finding the users inside the get_progress_all() method.
Triggering a fatal error in an adhoc task is bad. It will be retried indefinitely.
Even though we are not sure how to get a module instance without a course module record,
it is possible and should not kill the Moodle site.
- Icon generation logic moved to the course renderer.
- Web service should return the completion info only, not HTML.
- JS modified to handle icon rendering in relevant cases.
Peter Dias