Moodle

Should be mostly fixed, please test the latest version of both moodle 1.9dev and ouuser report from contrib. I have synced the code base of user and ouuser report, you can also select which report should be used in user profile. The css styling is now in grade/report/ouuser/styles.php.

Could you please explain more the dimmed_text for hidden items? At present only hidden grade items are grayed out (name of item and its category). Should we also dim complete row when individual grade hidden? This is very easy to fix, I just need to know exactly what is requested.

Thanks

I have tweaked the hiding implementation - please test and close if ok, thanks

First comment:

You say 'you can also select which report should be used in user profile'.

So with admin privileges on the 'Grade settings' page for the whole site I have chosen
'User profile report (grade_profilereport)' to be 'OU User report'.

My expectation was then that this would be the only report that students see. But when I go to view the grades as a student I still see, by default, the standard user report with the OU User report as a selectable report from the drop-down list.

Have I misunderstood this?

Second comment:

The number of submissions that should follow each mean has disappeared (again!). Could you put them back please.

Third comment:

You ask 'Could you please explain more the dimmed_text for hidden items? At present only hidden grade items are grayed out (name of item and its category). Should we also dim complete row when individual grade hidden? This is very easy to fix, I just need to know exactly what is requested.'

As you are asking about rows here I'm wondering if you are asking about the Tutor/Course staff/Helpdesk reports and not the OU User report. I would say that what I see in the Tutor/Course staff/Helpdesk reports today (in Firefox!) is fine and you need do no more on this aspect of the display.

Fourth comment:

The means in OU USER no longer reflect the settings for 'Grades selected for column averages'. We have had this set for some time to 'non-empty grades' and Screenshot-1 from last week does use non-empty grades, but today 'all grades' are being used.

Fifth comment:

I refer here to item 1 in the original description above. There I state that where there is a hidden grade the values shown for

• the mean of that item ('C' in screenshot-1)
• the Category total that include the hidden item ('D')
• the Course total ('E')
  should all become '-'. However today's OUUSER shows values for each of these items.

That's the final comment for today.

1/ the list of plugins is configured through capabilities - remove gradereport/user:view from all roles if you do not want to have User report in the list of available plugins; the selection for user profile is independent

2/ sorry for this regression, should be fixed now; fixed another bug when there were no grades yet

3/ working on IE6 issues - could you please try to switch to standard theme? I did several changes in css styles during the weekend, your theme might not be compatible - going to work more on this today

4/ I have added a new configuration setting for OU User - the all/graded is now independent from the grader report (reports should not share any settings)

5/ all report plugins share the same logic for recalculation of totals when hidden grades present - users with/without "view hidden grades" see different totals; in case of OU students and helpdesk see the same averages (excluding the hidden grades, dates may be enabled in global Grades settings), tutors see the averages that include hidden grades (the same what students will see after they be visible when quiz finishes)

1 I now understand the User profile report setting.

2 Thank you

3 We have now tried the standard theme and the heading became grey - so the problem is at our end and I'll put that into our bug-tracking system. Sorry for causing you unnecessary work.

4 This is working. Thank you.

5 Which just leaves C, D and E on the OUUSER report in screenshot-1. These are still visible and we don't want them to be when there are hidden grades. Everything you say is correct. The calculations for individual student averages with (for tutors and course staff) and without hidden grades (for students and helpdesk) looks fine. But in the example above we do not want students to see 'C' while a test is in progress, which in turn means that aggregates that contain 'C' have to be replaced by '-' too. That's 'D' and 'E' in the above example. Note that Helpdesk staff do not see any of 'C', 'D' or 'E'.

5/ I do not understand the reasoning behind this - but I can make it the way you want it, I am going to add a new switch for this, expect commit later today...

We have just noticed something odd about the dates that are now shown in the OUUSER report.

On screenshot-1 taken last week using the OUUSER report the date for the hidden grade is shown as 4th October 2007.

The report that we have generated today for Helpdesk staff still shows as 4/10/2007.
BUT today's OUUSER report shows the date for the same test as 19/10/2007.

Why?

eh I think I understand it now - 5/ should be fixed now - Mean (submission) now '-' if related user grade depends on hidden grades

6/ do you want to remove the mean (count) also when user grade visible, but grade does not exist yet?

The dates are a bit problematic - we do not have a real submission date stored anywhere - we are just guessing in gradebook, I will have to talk with MD about this ASAP
This is a known problem for me, we were able to work around it in several places, but I think a proper solution would be a new field in grade_grades table. I did not know how to solve this until this weekend, but I can not change the db structure now

That is a problem. We were using the dates to give reassurance to students that their submission has been registered and in our tests up until today the dates in the Gradebook did seem to correspond with the dates stored in the Quiz (as they should).

Can you describe how the dates that have appeared so far are obtained?

There are two sources - overridden field (updated each time a grade is overridden from the gradebook UI) and timemodified (updated whenever something changes in grade_grades record - which might be also locking, hiding, new grade received from activity). We are not sending the real submission/graded date into gradebook from activities.

Solution could be new field - "last_graded_date" in grades_grade table, I am going to create a new blocker bug for this and let MD decide.
Or change the meaning of existing timemodified field in all grade_xxxx tables

This comment refers to items 5/ and 6/ three comments above.

5/ is now fine. Hooray! Thank you.

And yes, we do need what you suggest in 6/.

Just to be clear I have attached as screenshot-3 the view for a student who has not yet done iCMA47. The '51.2% (5)' for this student should also be '-'.

(Please ignore the iCMA48 entry, I am testing the dates issue. Will read (and understand) your latest note before replying.)

6/ committed - both 47 and 46 are '-' now
or do you want 46 mean visible?

My comment on the dates issue

1 The key date is the date of submission. This is what we want to appear in the OUUSER report.

2 Our course teams will inevitably fiddle with settings such as locking and hiding. If 'hiding' includes altering the date that a quiz is 'hidden until' we will inevitably use this.

3 But I don't think that we will be particularly bothered about when settings affecting things such as locking and hiding occur.

4 I'm not at all sure what we should show in OUUSER if we override a grade from the gradebook UI. I would need to take advice on this but we would probably need some 'use cases' for our senior exams staff to pronounce one way or the other. For now I'd say that our spec. requests that the date of submission is shown and that's what we'll stick with.

Re. 6/ yes I want the mean for iCMA46 to be visible.

This student has not submitted anything for iCMA46 but as the quiz has now closed they can be shown how all their peers (i.e. fellow students) went on (and what marks they might have missed).

So only hide the 'mean (count)' where the grades are hidden until a future date.

6/ 46 fixed

the dates - it seems we need two dates:
1/ date of submission
2/ date of grading

ideally these should be stored in grade_grades table, if that is not approved by MD I can fetch the dates directly from modules, new required methods in grade_grade object:
grade_grade->get_submission_date();
grade_grade->get_graded_date();

I guess the label should be "Submitted xx.xx.xxx" instead of current "graded", right?

ok, the solution will be to use timecreated for original date of submission and timemodified for last change of grading, this needs some fixing in core classes, API and modules - should not be very difficult, expect fix tomorrow...

thanks

Regarding 6/46:
The 'mean(count)' for iCMA46 (which is a test for which results are available) is now in place even where a student has not made a submission. This is correct.
For iCMA47 (which is a test for which results are not yet available) this student has not yet submitted and their entry is a ''. This is correct. As the results for this test are not yet released the 'mean(count)' for iCMA47 is also shown as a ''. This is also correct.

It follows that for this student the 'mean(count)' for the Category and Course totals should also be shown as '-' and this is NOT correct in the latest implementation which shows the values that tutors see.

screenshot-4 shows the problem. Positions 'D' and 'E' should be '-'
screenshot-5 shows the situation for a student who has submitted iCMA47. Screenshot-5 is correct.

Regarding 'Graded' or 'Submitted'. We agree that it should be 'Submitted'.

Regarding the dates.

Your solution sounds fine. But can I just draw your attention to one current inconsistency which is that I am seeing different dates through OUUSER from those which I see through the Grader report when configured for the Helpdesk (which can't see hidden grades). I'm hoping that this the sort of inconsistency that will go away when you have changed things.

So through the Grader report I can see dates going back to September, whereas OUUSER shows much more recent dates for the same items. And I am sure that I have not altered all these grades via the Gradebook UI.

I can give one specific example. I imported some grades on 8/10/07. I have altered the value for one student today and re-imported. The Helpdesk report still shows 8/10/07 for all students. The OUUSER report shows 8/10/07 for students where the grade didn't change but 31/10/07 for the grade that did change.

However we have to be careful as so much has happened over the past 6 weeks. It might be that when you've made these changes we cover this ground again.

a/ I am working on the dates - it should solve the issues in grader and ouuser/user reports
b/ the hiding of mean totals - I will have to change the algorithms, it will be a bit slower but I think it should work the way you want it

Both a/ and b/ should be fixed now

I've just updated the system including the two updates for OUUSER.

At first glance OUUSER looks good ;~).

But this is a quick note that the Grader report is broken. I went in as a Helpdesk user to check that they see the same dates as OUUSER and got:
'Fatal error: Call to a member function get_datesubmitted() on a non-object in /var/www/html/icmatest/1.9/grade/report/grader/lib.php on line 684'

sorry, going to test/fix the grader issue today, I need to finish some other refactoring first.

edit: found the bug

The greader typo should be fixed in cvs now.

I have also refactored the code for item icons, please review it if it is ok for OU, if not I can tweak it or add some new configuration options. All reports and tree edit page (Edit/Items and categories) now share the same icons and links to activities.

We have checked the OUUSER report in all the ways that we can think of and all is well.

You may now close this item.

Just to let you know where we go now. It is over two months since we started testing the Gradebook and during that time much has changed. What we need to do now is ensure that everything that was OK back in September is still OK. So we are going to build a complete OU system and them test the whole of the Gradebook again, this time with a wider range of participants. We anticipate starting this circa 13th November and running forwards for 4 weeks.

So there might be further bug fixes during that time.

But for now all is well with OUUSER. Thank you.

Wonderful, thank you for the cooperation, it was nice to work with you

Petr