This has been generated running the following Sniff,
part of the Moodle's CodeSniffer standard:
- PSR2.Methods.MethodDeclaration
It just ensures all the function declarations have
the correct order for:
- abstract and final.
- visibility (public, protected, private).
- static.
So, all the lines modified by this commit are function declarations
and the only changes are in the positions of those keywords.
This change enhances the user experience in the grade report grader by
moving grade item weight calculations to the front-end. Previously,
these calculations were done on form submission, resulting in slower
performance and less interactivity.
With this improvement, grade item weights are now calculated dynamically
in the browser as users make changes, providing instant feedback and a
more responsive interface. This change improves the usability and
efficiency of the grade report grader.
This is only applicable to natural aggregation type.
Problem:
In Moodle 4.2, an unintended change in behaviour occurred when locking
and unlocking grade items. Previously, in Moodle 4.1, locking a grade
item and then subsequently unlocking the grade item left specific grades
for students still locked if they were being locked individually.
However, in Moodle 4.2, the unintended change caused the individual
grades to be unlocked along with the grade item.
Solution:
To address this issue, I modified the set_locked calls in action.php to
pass the cascade parameter as false. Now, when locking or unlocking a
grade item, only the grade item itself is affected, leaving individual
grades unchanged. I have also modified the locking behaviour in the
grade_category class. So, similarly, when locking or unlocking a grade
category, the change applies only to the grade items and grade
categories within the category, without expanding to individual grades.
Explanation:
By making this change, we ensure that the locking mechanism behaves as
expected, providing a consistent and desirable user experience. Locking
and unlocking a grade item or category will no longer inadvertently
affect individual grades, preserving their locked status and avoiding
loss of data when unlocking a grade item associated with the total mark
of a category.
In PHP 8.2 and later, setting a value to an undeclared class property is
deprecated and emits a deprecation notice.
So we need to add missing class properties that still need to be declared.
Co-authored-by: Andrew Nicols <andrew@nicols.co.uk>
This change makes the regrade progress bar send frequent updates to
the web browser, even when processing within the same grade item, to
avoid timeout problems when there are a large number of users.
Replace it for correct property_exists() when the element
being inspected is a property of object/class.
Amended and squased changes:
- keep mongo unmodified. The information is array, hence correct.
- fix a couple of messaging phpdocs that were incorrect.
Amended take#2:
- As far as mongo resturns BSONDocument that is ArrayObject, aka
implements ArrayAccess, we have decided to explicitly cast results
to array so existing array_key_exists() and other accesses will
continue working the same.
Some grade object (outcomes,scales) can be created at site or course
context, so this patch just makes sure we use the respective context
when applying format_string to the name in the get_name() function.
We can switch the cache to session level if we are able to purge
different users caches, not only the one that belongs to the user
updating a grade category.
All of these changes make use of already
fetched grade data. Without these changes,
the gradebook regrade process does not scale
well with very large courses because it fetches
many grade records, one at a time.
When we adjust the weights in natural grading (setup screen), the extra credit items
should not depend on other overrides. If extra credit item's weight was overriden, it stays as it is.
Otherwise it is calculated as itemgrademax / totalgrademax (total excludes extra credit items)
This setting is not compatible with combinations of aggregation methods
and the ways in which it does and does not work are not documented. It
was voted to remove it completely by the gradebook workshop, so I have
completely removed it and added a warning for all affected courses + restored
backups.
It can happen that some grade items with the type 'None' have a max
grade different than 0, in which case we would have set a weight for
them which is wrong as they must not have any. This patch always
ignores the grade items 'None' and 'Text' when calculating the
weights and locks the weight UI fields for those items too.
Used in aggregation was not resetting previously set values
when recalculating an aggregation. This meant that items no longer
in the aggregation, were displayed with stale weights in the user report.
