That helper, used to fetch information from DB by all the grade_object
chidren classes was not behaving properly handling TEXT/CLOB columns.
Instead of creating a property within every class listing the
existing columns, it seems to be a better solution to instrospect
the database metadata (cached) to ensure the correct SQL is generated
in every case.
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.
Eric Merrill