Affects Version/s: 2.3.x
Fix Version/s: None
Component/s: Gradebook Classic
2-3-x branch, r22069. User's browser is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20070219 Firefox/22.214.171.124
A TA entered a set of grades for a test in a course site with approx 240 participants. After all of the grades were entered, a further save grades operation took place, and 100 grades were incorrectly applied to a different set of students. This behaviour could not be subsequently reproduced in this or other sites.
Investigation of the app server log files and gradebook grading logs shows the following behaviour (as recorded by Sakai):
- All the grades were entered
- A set of 100 grades were saved. This was a set of existing grade values (i.e. entered previously for students), but they were applied to the wrong set of students. The grades were in descending point score for students ranked 101 - 200, but were applied to students ranked 1-100 (in descending point score).
The behaviour would seem to correlate with the following UI interactions:
- Enter grades in several batches (potentially arbitrary order)
- Sort the grades by descending point score order, with the page view set to 100 per page
- View the second page of students (i.e. point scores 101-200)
- (Possibly) save that page
At that point it appears that this group of scores was applied to the set of students ranked 1-100 rather than students ranked 101-200. Students ranked 1-100 therefore ended up with 2 scores in the gradebook, vis. the original correct score, and a second incorrect score corresponding with the score of the student 100 places down in the point score ranking.
Given the very exact way in which these scores ended up saved in the database, simple user error seems unlikely. The TA concerned did not recall any unusual behaviour such as opening the gradebook in multiple tabs/windows, or using the browser back button. He did report some instances in which he clicked the browser stop button and clicked Save again, fearing that a timeout may result in lost data entry.
There seem to be two possible scenarios that could account for this:
- Some browser behaviour caused an incorrect set of values to overwrite the values in the "page 1" form (i.e. students 1-100 in point score ranking), and the application correctly saved the values sent to it by the browser. This seems unlikely. The browser concerned did not have any addons installed, and as there would already be point score values in the form from the Gradebook, autocomplete wouldn't come into play.
- The JSF state id somehow became muddled, perhaps through multiple stop/save operations on the same form, causing the application to interpret a set of values as applying to the wrong page / set of students.
In either case, setting unique IDs (associated with a userid) on the HTML input elements for scores would provide an additional verification check that could prevent this type of error from happening again.