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)
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).
* Update completion_info::get_data() to add other completion
information from a new method called get_other_cm_completion_data().
This allows the storage of the completion statuses of the following
completion rules to completion_info objects:
- 'Students must receive a grade' completion rule.
- Any custom completion rule defined by an activity.
This allows detailed completion information to be fetched for course
modules.
It also allows custom completion statuses to be cached which will help
reduce DB queries when fetching completion statuses.
* Update update_state() to fetch overall completion state from the
module's activity_custom_completion implementation. Falls back to the
*_get_completion_state() callback function.
* Update internal_set_data() to include the other cm completion data
in the updated cache data for the module instance.
Move the current logic for determining the completion status for the
"Student must receive grade" completion rule to a function so it cann
be reused.
Unit test included.
Changes:
- Activities with auto completion and a completion status overridden to
COMPLETION_COMPLETE are no longer processed by normal completion
triggers.
- All activities can still be completed by students when their
completion status has been overridden to COMPLETION_INCOMPLETE, via
either auto or manual triggers.
- Completion unit tests updated
The completion cache is currently not marked as simpledata. On the
course page it is frequently retrieved hundreds of times which results
in many calls to the slow unserialize function. By making a slight
change to the data format (using arrays instead of objects) we can
mark it as simpledata, which will avoid using unserialize.
The badges feature allows to integrate Mozilla "Open Badges" to issue, assign,
manage and display digital badges in Moodle. This feature supports:
-- badge creation and issuing based on criteria
-- badge baking and verification service
-- direct pushing of internal badges to external backpack
-- interanl and external badge display in Moodle
-- Moodle block to display latest badges
