Associate column headings of user report tables to the user ID that the
report is being generated for. This will prevent duplicate IDs for the
report columns when multiple user report tables are displayed on the
User report page.
* The table cells mentioned in the `headers` attribute of other table
cells need to be using the table header <th> tag. Otherwise, HTML
validation fails.
After MDL-75762 the overall average row in the grader report
was no longer properly pinned and hidden behind the sticky footer.
This change ensures that the overall average row is pinned again
at the top of the sticky footer when vertically scrolling. Also,
leveragning on the new sticky footer 'toggled' event it is making
sure that the row is properly pinned on narrower screens where the
sticky footer appears and disappears dynamically when scrolling.
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.
In this commit, the front-end experience for grade item weights in the
gradebook setup page is refined, building upon the improvements made in
the previous commit.
Firstly, overridden weights are excluded from automatic adjustments.
This enhancement guarantees that user-specified weights remain unchanged
by front-end calculations, thereby preserving the flexibility of custom
weight assignments.
Additionally, front-end form validation has been introduced to enhance
the user experience. Now, users will see validation errors if they
submit invalid values, giving them the opportunity to correct the values
themselves. This ensures that weights are not automatically normalised
by the back-end code, preserving the values as entered by the user.
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.
* Use the appropriate gradebook plugin string for the page title.
* Improve gradebook page titles set by grade_get_plugin_info() by
listing the unique identifying information for the page first
(e.g. the gradebook plugin name), followed by broader information
(Grades + Course name), separating these bits of information using the
pipe `|` character.
For more information, check out
https://www.w3.org/WAI/WCAG21/Techniques/general/G88
This change includes some additional simplifications to support this
change, including conversion from done/fail to then/catch, and some
simplification of Promise usage.
There were a number of cases of nested Modal usage which have been
removed.
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.
A lock/unlock option is added to the context menu of the grade
categories again. But it is only used as an auxiliary tool to lock or
unlock all the grade items within the category.
Problem:
The grade_categories table lacks a 'locked' field, making it technically
impossible to lock grade categories. In Moodle 4.1, the "category total"
column could be locked (from the edit category form), but locking grade
categories directly was not supported.
Solution:
In response to the issue, the lock/unlock feature for grade categories
has been removed. Since the grade_categories table does not have the
necessary 'locked' field, attempting to implement category locking would
be infeasible. As a result, the feature has been removed from the
interface to avoid confusion.
Explanation:
By removing the lock/unlock feature for grade categories, we ensure that
users no longer encounter non-functional options and prevent any
potential misunderstandings about the locking behaviour. Additionally,
this change aligns the user interface with the underlying database
schema and eliminates any misleading functionality.
