For a long time, Moodle has had the feature to force the language
for a whole course. This change adds the same feature at activity
level.
The course-level feature was controlled by a capability
moodle/course:setforcedlanguage, and I decided to use the same
capability to control this feature. I think a new capability would be
overkill.
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
Before resetting completion states during module update, we need to
rebuild the course cache first in order to properly reset the completion
states. Otherwise, calls to methods that fetch course module info
via cache (e.g. cm_info::create()) will fetch outdated information.
This is the initial deprecation of:
* plagiarism_save_form_elements
* plagiarism_get_form_elements_module
* plagiarism_plugin::get_form_elements_module
* plagiarism_plugin::save_form_elements
In PHP the following are true:
assert('' == '');
assert(0 == '');
assert(null == '');
The options in the course completion settings are now:
'' => none selected
[int] => itemnumber of activity course completion item.
In the case where the itemnumber was 0 this was being incorrectly
evaluated as an empty string due to the implicit cast to int of the
empty string:
(int) '' === 0
As a result, the non-strict comparison means that the following are
identical:
assert(0 == '');
assert(0 == (int) '');
assert(0 == '0');
Changing the comparison to a strict comparison is correct because it
ensures the type consitency between the empty string value, and the int
of itemnumber 0. It is safe because the value always comes from the
form, where an int is always returned, and not the DB, where a string is
returned.
The default value is an empty string (""), which in PHP evaluates to 0 when
cast to a string in our DML layer.
The fix is to forcibly make it null which is not cast to string in DML
for optional strings.
Add field 'visibleoncoursepage' to the course_modules table
Add site-wide setting for turning on stealth mode availability
Add callback for "stealth" mode support in the course formats
Change display of modules/sections availability on the course page
This commit replace $e usage by $returnfromfunc.
Indeed $returnfromfunc always exists in the scope and take $e value in case of moodle_exception.
This commit also remove useless $modcontext affectation.
Default value of gradepass is 0.00000 and empty check
passes. But on oracle gradepass value is 0, so just
check if the field is set and that should be enough
3 new plugin callbacks are available to extend any course module form.
xx_coursemodule_standard_elements()
xx_coursemodule_validation()
xx_coursemodule_edit_post_actions()
This allows you to add elements to the form, extend the validation
and process the extra information once the module has been created/updated.
The completion fields are locked when a user has already completed the
task, to prevent you accidentally causing it to recalculate the data.
This lock doesn't apply to the expected date field, as this doesn't
affect user completion. However, changes to the field in this
situation were incorrectly not saved.
As part of the unit test modifications for this change, I added the get_json
function to the availability conditions that didn't have it. (This is a function
for use in unit tests.)
If an exception occurs during a module's _add_instance function, this
results in a course_modules entry with instance=0. The system already
handled returning false to this function, but did not handle
exceptions.
