Before this patch it was possible for the student displayed on the grading page to
not be the student that the user selected to grade. This would occur if:
1) The user had the table ordered by a value that could be modified,
for example Last modified (submission), Grade, Last modified (grade)
2) Another user performed an action that was recorded in Moodle in the time
between the user generating the table and clicking on a grade link.
If a user did not notice a different user had been loaded it could result in them giving
a grade to the incorrect user.
This patch ensures that the state of the table is cached every time it is viewed by a user
who has the capability to grade.
The problem with the previous implementation was that the table's
$this->prefs can contain valid non-empty value in its default state -
the default column to sort by. On resetting, we must not throw away
these default prefs.
This patch simplifies the TABLE_VAR_RESET interpretation. If such an
HTTP parameter is passed via the request, the table simply behaves as if
there were no previously stored preferences (does not matter if coming
from the current session, or from the persistent cross-session storage).
The logic that decides on whether or not the reset widget should be
displayed is put into a new method can_be_reset() with unit tests
attached.
Finally, the previously private method render_reset_button() is now
protected and the reset widget is given a new semantic CSS class.
This change stores the list of columns that require text sorting in the session,
so the static function "get_sort_for_table" can work without any additional parameters.
This includes refactoring to extract methods like sort_icon and show_hide_link which I think makes the code easier to read.
Note also the change to make_styles_string that makes it usable with html_writer. (Perhpas we need a css_writer classe ;-))
You may think that the extra validation is unnecessary, since the sort fields are already validated when the URL parameters are parsed, however that overlooks an important point. There may be other options that affect which columns are in the SQL, for example the quiz show individual question grades setting. These other options can cause a column that was in the table, and being sorted on, to disappear. Therefore, it is necessary to re-validate the sort columns when they are used, to make sure they are still present, otherwise you can get ORDER BY sql that refers to non-existant columns, which then causes DB errors.
Neill Magill