From Martin Dougiamas (martin at moodle.com) Wednesday, 26 March 2003, 09:47 PM:
If the grade is zero and the feedback is empty, then the new results should not be overwriting existing results. (see the bit in http://moodle.cvs.sourceforge.net/moodle/moodle/mod/assignment/submissions.php with the comment Only update entries where feedback has actually changed.)
However, I can see a problem if two teachers are marking the same assignment at the same time (for example if they both set a new grade and both hit send, then the first will be overwritten by the second - I assume this is the scenario you meant to paint). In a way this is a teacher communication problem, since it can happen with pretty much ANY grading system).
But you're right - it should be fixed.
#1 sounds a bit like my new journal module - see MDL-285 and the reference there to MDL-100. This is probably the way to go, I think, as it also allows for resubmitting assignments. A new assignment option could be show all feedback and show only most recent feedback.
#3 sounds good but depends on groups of course. it should be optional, since it'll add some management load (single teachers don't need it for example)
What are your thoughts afer reading this?
From Greg Barnett (gregb at crowncollege.edu) Thursday, 27 March 2003, 03:40 AM:
I just retested to be absolutely positive, and in the case I presented, Foo's feedback and grade are overwritten with an empty comment and a grade of zero.
I did get my names messed up though. Foo's feedback for Eggs should be Foo's feedback for Spam. And yes, this only happens when multiple teachers are grading the same assignment simultaneously (something which is very common for my installation of moodle).
The way submissions.php checks for change is the problem. It is checking against the database (which is current), instead of what the teacher was looking at (which can be different that what is in the database if another teacher has submitted feedback since the page was opened).
A possible fix for this would be to add hidden fields for old grade and old feedback, and only do an update to the database if the values for old grade and feedback are different. If the old grade/feedback are not the same as what is currently in the database, inform the teacher that the data has changed, and give them the option of overwriting old feedback or not.
Another possibility is some sort of locking mechanism. If a teacher opens up the grading page, give them the same amount of time as in maxediting time, if anyone else tries to open the page before the time is up or grades have been submitted, give them an error message.
From Martin Dougiamas (martin at moodle.com) Thursday, 27 March 2003, 10:43 AM:
Yes, I like that. A md5 checksum would be the best way to do this, I think, to save bandwidth.
So, each submission includes a hidden md5 checksum for the current text, and a hidden field for the current grade, which gets compared against the new incoming feedback and grade.
If either are changed, then check the old values against the database. If these are the same, then save the new ones normally. If these are not the same, then print a conflict resolution page listing all the conflicting entries (database and new), perhaps side by side, with checkboxes to select the correct one from each pair.
I think that sounds OK - how about you?
From Martin Dougiamas (martin at moodle.com) Thursday, 27 March 2003, 10:45 AM:
er radio buttons, not checkboxes
From Greg Barnett (gregb at crowncollege.edu) Thursday, 27 March 2003, 02:24 PM:
I think as a quick fix, the md5 comparison is the best bet. One additional twist that I think will improve usability: if grade was 0 and feedback was empty, but someone else has already updated the grade/feedback, and the user is sending back 0/empty, assume that the first person to submit a grade/feedback wins the conflict.
Long term, I like my #1 idea / MDL-285 approach of treating feedback more like a discussion.
I have assigned this one to me, as I think I can probably fit this into my workload over the next week or so. If anyone else wants to tackle it, I won't object though (though I'd appreciate an email so that I don't spend time duplicating work).
From Martin Dougiamas (martin at moodle.com) Saturday, 29 March 2003, 07:47 PM:
All yours if you can fit it in!
From Greg Barnett (gregb at crowncollege.edu) Friday, 11 April 2003, 03:58 AM:
Haven't been able to get to this yet, but one minor change to the approach I'll likely take:
Instead of using md5, pull the timemodified, and put it in hidden fields. Also put a hidden field in with the time the form was generated. When the form is submitted, compare the two timemodified to make sure it hasn't changed since the form was viewed.
From Martin Dougiamas (martin at moodle.com) Sunday, 13 April 2003, 02:39 PM:
I've not had a deep think about using timemodified but it sounds like it will work just as well.
From Greg Barnett (gregb at crowncollege.edu) Thursday, 8 May 2003, 04:54 AM:
I just committed a change, that I am fairly certain fixes this issue without causing any new problems.