* When toggling bulk editing, updating the page's title can help users,
especially screen reader users, to determine the current editing state
of the course homepage.
* Create 'editing' versions of the coursetitle and coursesectiontitle
lang strings used for the page title of the course homepage and use
these when editing mode is turned on to provide immediate information
to users, especially screen reader users, the current state of the
course homepage.
* Add a new way to extend the BigBlueButtonBN form via subplugins
* Allow subplugins to extends information via new tables and use it in
the edit form.
* Add a new cache helping with potential perfomance issues introduced
by recurring calls to find out about associated tables in subplugins.
1. Modified the password related forms
2. Added a new constant in moodlelib.php called MAX_PASSWORD_CHARACTERS
3. Added a new method in moodlelib.php called exeeds_password_length
4. Updated the upgrade.text
* Fix tag area text shadow colour. It is originally set to
`rgba(255, 255, 255, 0.5)` so it should be `rgba($white, 0.5)`
instead of `rgba($black, 0.5)`.
* Revert colour for `$content-item-unread-colour` to `#f4f4f4` instead
of `$gray-100`.
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.
Problem:
When the aggregation method is set to "natural," grade items' weights
and the maximum grade of the grade category's item get recalculated,
causing the needsupdate flag to be set to true. As a result, the locking
process was skipped, leading to unexpected behaviour.
Solution:
To address the issue, the set_locked method has been modified. Instead
of skipping the locking process, the method now schedules the locking of
grade items to occur slightly in the past, specifically one second in
the past. This ensures that the grade item will be automatically locked
after the recalculations are completed.
Explanation:
By making this adjustment, we ensure that the locking process is not
skipped during natural aggregation, maintaining consistent behaviour and
preventing any unintended consequences related to grade item locking.
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.
This addresses a random failure with the combobox search results where
the debounce causes the results to be shown, and then the same search
result is returned again, re-rendered, and replaced after Behat has
moved on.
Add a pepper to the users supplied password.
The pepper is stored in CFG and user to add extra security to
the password hash. By effectively breaking the information to
create the hashed password into two and storing it in more
than one place.
