Avoids validating form data which is carried over from the
simple dynamic form to the advanced form page when creating
or editing grade items, categories and outcomes in the
Gradebook setup.
Fixes an accessibility violation in the gradebook setup page
related to the insufficient spacing between the select checkbox
elements and the 'move' icon.
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 grade_edittree_column_status::get_category_cell, an assumption was
made that $category->grade_item is always populated. However, this was
not guaranteed, leading to potential issues.
Solution:
To ensure $category->grade_item availability, a $category->load_grade_item();
call was introduced in grade_edittree_column_status::get_category_cell.
This guarantees safe usage of $category->grade_item.
Furthermore, in grade_edit_tree::build_html_tree, $category->get_grade_item()
was replaced with $category->load_grade_item() for enhanced reliability
and potential performance improvement.
Explanation:
These changes enhance robustness and efficiency in gradebook.
Addressing incomplete grade item handling improves code reliability and
user experiences.
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>
Previous to this, heading logic was performed in print_grade_page_head.
With the deprecation of the showtitle param, it makes sense now to
explicitly set the heading when the function is called. This prevents
duplicated text between the heading and teriary dropdown. This patch
also fixes unnecessary text that was concatenated onto headings.
Ensure the saved values for the hidden and hidden until fields are
populated when editing a grade category. Fix behaviour on enabling
the hidden until field.
Re-enable tests commented out in eba1d32c.
Create or update the breadcrumbs in the site administration
pages where it is required.
Highlight the corresponding site adminstration tab.
Highlight the primary nav to Site administration when user
is navigating to any of the site administration pages.
Also changed the boostnavbar so that the nodes in the secondary
navigation are not shown in the breadcrumbs when user is in site
administration page.
It has been detected, thanks to php80 specially, that there are
various places in core where support for localised floats is
missing. Before php80, some locale-dependent conversions were
performed by PHP, allowing things to work. But with php80 all
those comparisons are now locale-independent. See:
https://wiki.php.net/rfc/locale_independent_float_to_string
That implies that we now need to, always, unformat floats to
be internally the correct (decimal point as separator) in
order to compare it.
While this was visited in the php80 epic (MDL-70745), nothing
was found, all automated tests were passing ok. Problem is that
we run behat tests with en-AU laguage that has the decimal point
separator.
So, in this issue we are fixing all the problems detected by
running those Behat tests using localised (comma) decimal
separator.
Note that there may be other places still causing problems, but
it's really hard to find them programmatically, so we'll have to
wait for real use reports / issues and go fixing them while they
happen.
Back to this commit, this is the list of changes performed (note that
in the next commit, we'll be adding scenarios explicitly using
a localised decimal separator to ensure that they work ok).
A. Changes to various grade forms to ensure that, on their validation
floats are unformatted properly. Also, changed the corresponding
form element from current text/PARAM_RAW to proper float ones that
take care of the conversion in a number of places (but when disabled,
that's the reason we still have to unformat in validation.
This includes the following forms:
- edit_category_form
- edit_item_form
(this is the original problem reported that cause all the research
to be performed against full behat runs)
B. Changes to edit_letter_form, so it uses a proper PARAM_LOCALISEDFLOAT
(note this is the type of change that surely should be used for all
the rest of /grade/edit/tree form, including those in the previous
point).
C. Changes to the grade_item behat generator, so it's able to work with
localised floats, un-formatting them when needed.
At lib/behat/classes/behat_core_generator.php
D. Fix problem passing localised floats to scales, not displaying
properly. At grade/report/singleview/classes/local/ui/finalgrade.php
E. Change the behat text matcher in order to allow comparison of
localised floats when they are the current ones. Before this change
the matches was using soft/lazy comparison, so '50' and '50.0000'
match. Now, when the comma (for example) is used (and only then),
'50' and '50,000' will also match. This comparison is in use in a
bunch of tests and makes sense to make it localisation-aware.
At grade/report/singleview/classes/local/ui/finalgrade.php
F. Fix a couple of number_format() uses in lesson, because they are
not localised-aware. Switched to format_float(). At mod/lesson/locallib.php
G. Change the quiz_contains_the_following_questions() step to accept
localised maxmark expectations. At mod/quiz/tests/behat/behat_mod_quiz.php
H. Change the quiz generator so it accepts localised gradepass.
At mod/quiz/tests/generator/lib.php
I. Change the edit question form to show proper localised penalties,
previously it was always showing point-decimal ones. Of course,
leaving the values of the select element unmodified (internal floats).
Related, also change a couple of tests to, instead of try to match the
value (always internal floats), match the description (now localised),
so we can test them with different separators. At:
- question/type/ddimageortext/tests/behat/backup_and_restore.feature
- question/type/ddmarker/tests/behat/backup_and_restore.feature
- question/type/edit_question_form.php
Ilya Tregubov