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.
Adding an activity with a grade item previously triggered a course
regrade, which can be extremely slow. This change makes it so that on
courses where regrading is slow, when you add an activity that
requires regrading, it takes you to an intermediate screen with a
progress bar.
This change also fixes a bug in the existing grade overview report,
which shows grades across multiple courses, but previously only
checked, and if necessary regraded, one course.
Set needsupdate to finish to avoid regrading each call.
Add error messages for regrading.
Display the error message on the quiz page.
Co-authored-by: Mark Johnson <mark.johnson@catalyst-eu.net>
Current code was relying on grade_floatval() that is not a validation
function. Instead, the gradepass field must be defined as proper float
and then perform the needed validations using unformat_float().
Note that the float element form has some particularities, see
MDL-73994 for more information and that makes us to have to check
for some values (null, zero) manually. Once that form element type
gets its behaviour fixed, the code will need to be revisited, hence
we have annotated it as comments for easier finding it in the future
(the same changes already were applied to other gradebook forms).
Also, remove an unreachable line of code (comparing with empty string)
within the grade_floatval() function because it's not possible anymore
to pass any string to it, as far as it's "?float" typed.
Covered as many cases with quiz completion as have been able to imagine.
This change prevents the printing of header when the
moodles page's state is STATE_IN_BODY. Due to the absence
of this check when user entered graded in bulk was causing
errors.
It has been detected that, right now, some localised floats are
being passed to those functions (say comma separator, say thousands)
and that's leading to all sort of problems later when comparing,
processing or storing those "wrong-floats" (user entered).
This just makes all those functions to be stricter, so any attempt
of passing to them a wrong float will fail with a clear TypeError.
Any existing case must be converted to a corrrect (X.Y) format, using
unformat_float() or PARAM_LOCALISEDFLOAT before any processing.
Localised floats cannot be used.
Also, fix all the places where those functions are called from
files having strict_types enabled because, with that, now float-like
strings are not accepted any more. Luckily, there is only case,
within the grade/classes/component_gradeitem.php file, and it has
been fixed by casting the float-like string coming from DB to float.
In the get_grade_letters there is a static variable that is used
to cache grade letters, we should use MUC for this so that it is
reset properly between unit tests.
This commit reviews all continue uses in core happening within a
loop / switch / case hierarchy. This does not cover:
- Changes to libraries. Will be handled in another issue / commit.
- Uses out from loops, will be reviewed by other commit.
The policy followed has been:
- When possible, take rid of the continue.
- When clearly the intention was to jump to next element in loop
change to continue 2
- When it was not clear, keep old behavior switching to break, no
matter how weird the behavior may be.
As we experienced in a bigger moodle.org course (7500 users, 70 grade
items), the standard memory limit 256M may not be enough here. We were
not able to find any obvious memory leak in the processing. Requiring
extra memory helped in this particular case and it seems reasonable to
have it in the core.
The grade settings page displays a message to inform users that weights
have been adjusted if they did not previously add up to the required 100%.
With the change to sometimes displaying a progress bar, whether the message
is displayed must be calculated immediately after the regrade took place,
and before the page redirects.
I have added a callback with arguments to the regrade_if_required function
which is called immediately after regrade has taken place (regardless of
whether the progress bar is required).
This callback modifies the PAGE URL such that the redirect message will be
displayed after the redirect. This does not use the session as the message
should only be displayed immediately after a change. If the user does not
click on the continue button after the progress bar has been displayed, and
comes back to the page later, this may be confusing.
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
