It's still not perfect, but this is getting closer.
This is based on Johns work on MDL-47009 (just the algorithm). There are some additional
changes to scale the weights if they do not add up to 1.
Part of: MDL-46576
Before this patch we would be marking some items as 'needsupdate'
during an update. Leaving them aside and not effectively updating
them.
Part of: MDL-46576
Includes all the conditions that were in previous Moodle versions:
* Date
* Grade
* Completion (of another activity)
* User profile field
Also includes conditions that are used to reimplement
groupmembersonly:
* Grouping
* Group
For each condition, the component plus unit tests are included.
PLEASE NOTE: The code to actually check each condition is reused
from previous Moodle versions and has not been modified except to
pass codechecker. This is intentional, to reduce the risk of the
change and maximise the chance that behaviour is preserved. Some
of this code might not be very good and might need updating but
that can happen separately.
AMOS BEGIN
CPY [contains,core_condition],[op_contains,availability_profile]
CPY [doesnotcontain,core_condition],[op_doesnotcontain,availability_profile]
CPY [endswith,core_condition],[op_endswith,availability_profile]
CPY [isempty,core_condition],[op_isempty,availability_profile]
CPY [isequalto,core_condition],[op_isequalto,availability_profile]
CPY [isnotempty,core_condition],[op_isnotempty,availability_profile]
CPY [startswith,core_condition],[op_startswith,availability_profile]
CPY [completion_fail,core_condition],[option_fail,availability_completion]
CPY [completion_pass,core_condition],[option_pass,availability_completion]
CPY [completion_complete,core_condition],[option_complete,availability_completion]
CPY [completion_incomplete,core_condition],[option_incomplete,availability_completion]
AMOS END
The completion system has code which is supposed to prevent it
updating completion status while grades are being restored. This
code was a nasty hack and had not worked for some time. As a result
completion dates were restored incorrectly.
This commit implements a 'proper' way to find out if a restore is
currently running, replacing the previous hack.
While restoring course/activity, restore will blindly insert grade_item
sortorder. Which cause dulicate sortorder and lead to unpredicatble sorting
results.
Now we will call grade_item::fix_duplicate_sortorder() after restore is finished
to fix duplicate sortorder and order grade items to the closest order possible
mod_assignment has been replaced with a stub that only exists to support restoring and
auto upgrading to mod_assign. If you require mod_assignment for some old plugin, then
overwrite with the 2.6 version manually.
Change from/to GRADE_AGGREGATE_WEIGHTED_MEAN and GRADE_AGGREGATE_EXTRACREDIT_MEAN was only
handled prior to this patch. GRADE_AGGREGATE_SUM and GRADE_AGGREGATE_WEIGHTED_MEAN2 also
behave similar and should be handled same way
This is a followup to MDL-18301. That fix missed the following points:
1. On the edit categories and items screens, all items had an eye-con to
control the visibility, even if the visibility was controlled by the
module.
2. Changing the visibility of a grade category change the visibility of
all items within it, even if the visibility was controlled by the
module.
3. The quiz ingored $cm->visible when controlling whether its grade item
was visible.
