* The activity link is now always it's view.php page;
* The user fields in the grader report are now initially sorted via the
cell action menu (ascending/descending).
This has been generated running the following Sniffs, all
them part of the Moodle's CodeSniffer standard:
- PSR12.Functions.ReturnTypeDeclaration
- PSR12.Functions.NullableTypeDeclaration
- moodle.Methods.MethodDeclarationSpacing
- Squiz.Whitespace.ScopeKeywordSpacing
All them are, exclusively, about correct spacing, so the changes
are, all them, only white space changes.
Only exceptions to the above are 3 changes what were setting the
return type in a new line, and, when that happens, the closing
parenthesis (bracket) has to go to the same line than the colon.
Various re-factors over recent releases appear to have led to quite a
drift between actual functionality and what these scenarios assert for
imagined functionality. Page elements and content are referenced that
don't exist in multiple places.
In certain scenarios, a user row can be the last row in the grader
report table. The current logic does not take this into account and
always pins the last row regardless of the type.
This change ensures that the last row is not a user row before executing
the logic responsible for pinning this row.
When we have a pagination on grader page and search for user
that is not on first page, saving was throwing an error
since page didn't have enough data
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.
Problem:
Previously, when users pressed the Enter key while interacting with the
grader report, instead of submitting the form, a table column was
inadvertently expanded or collapsed. This behaviour occurred due to the
expand/collapse buttons lacking an explicit 'type' attribute within the
form. As a result, these buttons were mistakenly treated as submit
buttons.
Solution:
In this commit, we have addressed the issue by ensuring that the
expand/collapse buttons now have the correct 'type' attribute set,
explicitly identifying them as non-submit buttons. This adjustment
prevents them from interfering with form submission unintentionally.
Explanation:
By making this fix, we improve the user experience in the grade book,
allowing users to navigate and interact with the interface more
smoothly. Pressing the Enter key will now trigger the form submission as
expected, rather than inadvertently activating expand/collapse actions.
