In MDL-78744, when the overallcompletion state was added to be displayed
in the activity card, only COMPLETE/INCOMPLETE status were considered.
However, depending on the activity completion settings, there are a
couple of states more that should also be included (COMPLETE_FAIL and
COMPLETE_PASS).
A new method has been added to the cm_completion_details class to
calculate whether a module should be considered or not completed,
based on their completion options and the current value for the
overall complete state.
When creating a new activity we should use course level default completion
and site level completion if there is no course level default completion.
For non defined default completion values use COMPLETION_TRACKING_NONE
instead of COMPLETION_TRACKING_MANUAL.
This commit displays all the module forms together in the default
activity completion page:
- The checkboxes have been removed. Now the activity names are
displayed as accordions.
- Module names have been changed from plural to singular.
- The activity completion form is displayed below each module name,
when the chevron icon is expanded. The cancel button is not displayed.
- The CSS has been updated to meet the prototype styling.
Reuse the code between default course completion settings and
activity completion form to avoid duplicating efforts and missing
features, as happened with the grading forum.
Some calls to the external_multiple_structure's constructor incorrectly
pass parameters where the value for the $description parameter is not
being passed. This results to invalid values being passed for the
$required parameter.
SQL was fetching activities where completion state was 'completed,
but not passed reqyured grade'. For course completion such states
must be ignored.
Also fixed progress bar on my courses page. Same reasoning as above.
- 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)
Amaia Anabitarte