[LON-CAPA-admin] Submission issues

[Lucas, Mark]

Stuart,

I may try the 2.11.1 msudemo server. Thanks for the suggestion.

Mark

On Jan 24, 2015, at 12:34 PM, Stuart Raeburn <raeburn at msu.edu> wrote:

> Mark,
> 
>> My question at this point is whether there is anyway sanctioned way   
>> to clean this up or whether the last part
>> is basically a hand-graded problem at this point.
> 
> The forthcoming 2.11.1 release provides a method for use by a Course  
> Coordinator to convert a submission of the type you describe to  
> "hidden".
> 
> Specifically, for transactions displayed in the grading menu with the  
> "all submissions with details" option selected a "Hide" checkbox is  
> included for any transaction where the solved status for a part  
> changed from correct to incorrect in the case where:
> 
> (a) question type was not survey (anonymous or otherwise)
> (b) this was not bubblesheet grading
> (c) feedback on display of correctness to the student is enabled
> (d) there was no "reset status" action between the submission of the  
> correct and
> the incorrect.
> 
> Checking the "Hide" checkbox(es) for the specific transaction(s) and  
> then pushing the "Save & Next" button will convert the transaction(s)  
> to hidden, such that the solved status will change from "incorrect" to  
> "correct".
> 
> Although my policy is to avoid making modifications between releases  
> to LON-CAPA installations in the production cluster, which involve  
> more than a simple one or two line change to a single module, I have  
> not adhered to that in this partcular case when updating the msudemo  
> domain LON-CAPA server (s12) with the changes needed to support the  
> grading menu functionality described above.
> 
> So, if you would like to log-in to that server (switching the domain  
> from the default to ohiou), you will be able to use this 2.11.1  
> functionality to clean-up this particular instance of bug 6740 for a  
> multi-part problem for one particular student in one of your courses.
> 
> On a separate note, in the 2.11.1 release I also expect to include  
> other changes discussed in my comments in bug 6740, which should  
> eliminate the original "race condition" itself, assuming no issues are  
> seen during upcoming stress testing.
> 
> 
> Stuart Raeburn
> LON-CAPA Academic Consortium
> 
> 
> Quoting "Lucas, Mark" <lucasm at ohio.edu>:
> 
>> Hi,
>> 
>> I've got another instance of the race condition (Bug 6740), I think,  
>> but it is on a multiple
>> part problem. The student entered a value for part 3, was asked for   
>> more digits, entered
>> more digits, then has a later submission that was hanging around in   
>> process with fewer
>> digits.
>> 
>> The student was then able to answer part 4 (unit issues, and too few  
>> digits again!), then put
>> another answer in a few seconds later. He then has about 10 entries   
>> with no information recorded.
>> 
>> My question at this point is whether there is anyway sanctioned way   
>> to clean this up or whether the last part
>> is basically a hand-graded problem at this point. Presumably I could  
>> go into their submission
>> db file and yank the offending submissions, but that's a bit risky.
>> 
>> Later,
>> Mark
>> 
>> --
>> Mark Lucas 								email: lucasm at ohiou.edu
>> 252D Clippinger Lab						phone: (740)597-2984
>> Department of Physics and Astronomy		fax: (740)593-0433
>> Ohio University
>> Athens, OH 45701
>> 
>> _______________________________________________
>> LON-CAPA-admin mailing list
>> LON-CAPA-admin at mail.lon-capa.org
>> http://mail.lon-capa.org/mailman/listinfo/lon-capa-admin
> 
> _______________________________________________
> LON-CAPA-admin mailing list
> LON-CAPA-admin at mail.lon-capa.org
> http://mail.lon-capa.org/mailman/listinfo/lon-capa-admin

-- 
Mark Lucas 								email: lucasm at ohiou.edu
252D Clippinger Lab						phone: (740)597-2984
Department of Physics and Astronomy		fax: (740)593-0433
Ohio University
Athens, OH 45701