Moodle

Hi Phil, I think if you try to save a value outside the range, you will get the maximum value in the range. For example in this case if you try to save, Carol Downie's score for iCMA41 should be 7, not 99. Validation is done after you click on 'Update'.

Cheers,

Yu

Hi Yu,
I had to go back and check what our Exams office was complaining about and this was not aided by a parallel bug about the quiz which does allow scores outside of ranges. I mistakenly thought it was the same complaint but it wasn't. I can now be clearer.

We see that the Gradebook does validate scores that are manually entered but the request is that such validation does not make automatic corrections but instead flags in some way that errors have been detected.

So if the range is 0-100 and one of our exams staff inadvertently enters 666 instead of 66 we wish to be informed of the problem rather than the system 'correcting' 666 to 100. As the editing interface allows for multiple scores to be entered so we would be wanting the feedback to allow for multiple errors to be reported too.

Could that be done?

Sorry for not being clearer earlier (the parallel problem with the quiz has been reported into our own bug tracking system for Tim to attend to).

Phil

Hi Phil, I added some code so that after you submit a grade that's outside the bounds, you will get a notice. The notice will tell you the activity and the student name.

Cheers,

Yu

Hi Yu,
Oh so close!

Firstly, what you've done to fix this bug is acceptable.
However the table now appears in a smaller font than the rest of the site. Go back to another part of the site and the font is 'normal'; view the table and it's smaller.

Can you fix that? Quickly?

And just to let you know that we've now been all the way through our full test plan for the Gradebook and I don't expect to be reporting any more issues as part of our Gradebook contract with Moodle.com.

If you can fix this small font issue I'll tell Dean Taylor, the OU VLE Programme Manager that the Gradebook contract is done and we can officially agree that the contract is complete.

I'd like us to take your latest updates before the weekend so that we can roll them into our system before Christmas; we're launching our latest version of our VLE on 8th Jan 2008 and we intend to pass the first results through the Gradebook on 14th Jan 2008.

So if you could do the fix asap that would be appreciated.

And thanks for all your efforts.

Phil

I don't like the way this fix has been implemented. I don't think that grade_item::update_final_grade should ever output notices, it is too low level. It is called from other places where that might be inappropriate. I think the check and the notice should be in the user interface layer. Nicolas, you know more about these classes than me, am I right about the intended architecture here?

Phil, the smaller font is a recently added feature, and is not related at all to this issue (see MDL-11835).

Tim is correct, the notices should be output by the report code, not by the grade_item class.

If the font size change is deliberate and not a slip that's ok.

OK, code fixed now. Nic, could you review it to see if I have done the right thing.

Actually, this is still not ideal. The processing is done before print_header, so any notifys break HTML strict.

Ok, fixed that bit too.

Thanks guys!

null not treated properly, max instead of min typo
and pretty please initialize all objects properly

reclosing, fixed in cvs

eh, this is not good - the changes in index.php break reloading of final grades!

reclosing again, should be working fine now