Upgrade from 2.6 to 2.8 course total not calculating grades correctly

Upgrade from 2.6 to 2.8 course total not calculating grades correctly

by James Henestofel -
Number of replies: 14
We just upgraded from 2.6 to 2.8 and our gradebooks are not calculating correctly.

In the one course there is only the course category and no others.  It's aggregation is "simple weight mean of grades".   "Exclude empty grades" is checked.

Before the upgrade the course total showed correctly.  After the upgrade all the totals show either an A or an F.  The max grade is 500 points and students with a point value of 164 say they have an A.

The only way I can fix the calculation is to backup and restore the course OR go into setup -> categories and items and edit the course category.  I uncheck the "Exclude empty grades" and save which I'm assuming forces a recalculation.  If I go in the gradebook it is fixed and shows the correct letter grade.  I then go back in and check "Exclude empty grades" and the gradebook still shows the correct letter grade now.

In another course it's aggregation is "weighted mean of grades" with "Exclude empty grades" as unchecked.  It has multiple sub categories. I have to do the same as above only checking then unchecking on the main category.

I've tried turning editing on and off tons of times and the gradebook won't recalculate.  Also tried manually editing a grade.  How can I fix this?  Can I force a recalculation of all gradebooks in my system(4400 courses)?

I've attached screenshots of what I'm seeing

https://moodle.org/pluginfile.php/179/mod_forum/post/1255617/gradebookcategorysetup.png
https://moodle.org/pluginfile.php/179/mod_forum/post/1255617/gradebooksetup.png
https://moodle.org/pluginfile.php/179/mod_forum/post/1255617/gradebookbeforefix.png
https://moodle.org/pluginfile.php/179/mod_forum/post/1255617/gradebookafterfix.png
In reply to James Henestofel

Re: Upgrade from 2.6 to 2.8 course total not calculating grades correctly

by James Henestofel -

After some more investigating I noticed that when I first click on User Report and no student is selected the course total range shows as 0-500.  But when I select a student the course total range shows 0-100.  Why is it doing this?

Attachment userreportstudentselected.png
In reply to James Henestofel

Re: Upgrade from 2.6 to 2.8 course total not calculating grades correctly

by Emma Richardson -
Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers

Sounds like maybe one report is set to display as real grades or points and the other is set to show as percentage.

In reply to Emma Richardson

Re: Upgrade from 2.6 to 2.8 course total not calculating grades correctly

by James Henestofel -

Nope they are all set to real(letter).  This is happening to a LOT of our courses.

In reply to James Henestofel

Re: Upgrade from 2.6 to 2.8 course total not calculating grades correctly

by Elena Ivanova -
From what I see all Ranges for Categories and Course Totals are getting messed up after the upgrade. 

E.g. before 2.8 the Range  for Category would be 0-200 points (100%). 

It is still set to 200 points in Category Settings. However, once you look at the user report/calculations -  it is calculated like it is out of 100 points.

So student who got 150 points before out of possible 200 points in a category/course, now will have a grade calculated as 150 points out of possible 100 points.

Which changes all final grades, of course. 

I am looking more to confirm this behavior.

Screenshots

Setup

setup


User report

user report


You can see how this student got 100%, which is incorrect (unlimited grades are not allowed, otherwise that number would be higher - 197%)

In reply to Elena Ivanova

Re: Upgrade from 2.6 to 2.8 course total not calculating grades correctly

by James Henestofel -

Elena,

That is exactly what I'm seeing.  I'm waiting on my hosting company to run the query Bob Puffer suggested to see if it fixes anything.

In reply to James Henestofel

Re: Upgrade from 2.6 to 2.8 course total not calculating grades correctly

by Bob Puffer -

  1. What version of 2.8 are you using?
  2. You can force recalc of all course with this query:

UPDATE mdl_grade_items set needsupdate = 1

WHERE itemtype = 'course'

In reply to Bob Puffer

Re: Upgrade from 2.6 to 2.8 course total not calculating grades correctly

by James Henestofel -

We are on 2.8.5

I'll have to see if my hosting company will run that.

In reply to James Henestofel

Re: Upgrade from 2.6 to 2.8 course total not calculating grades correctly

by Bob Puffer -

This is a summary from exhaustive efforts testing the gradebook by University of California, Santa Barbara Steve Miley and his team. He asked me to post it here:

After countless hours of performing test upgrades from 2.5 to 2.8 and comparing grades and other things in the grade book, we’ve come up with a plan on how we are going to do this upgrade.

You need to be cognizant of the current issues with the grademax issue.   This is really important.  There are two tracker issues on this.  You need to decide how your institution wants to deal with this.  We’ve decided that we will always keep in sync the grade_items.grademax with the grade_grades.rawgrademax.   
We update those values after the upgrade with an sql command, and we’ve made a change to the source code for our implementation of the grademax fix. (there are 3). 
Tracker items 

We had set in 2.5,  to have the default for sum of grades to aggregate only non-empty grades to true (even though you couldn’t change it in the gradebook setup simple view (but could in the full view).   Since it didn’t really work,  we ran an SQL command to fix the existing records on update. 

We did a number of tests on about 7000 courses,  we did the upgrade and recomputed all grades.  we then checked the grades and identified about 1% of the courses which had student scores change (note - this was 10% before we applied our grademax fix) .     We did another test, where we “locked” the scores (in grade grades), and ran a recompute.  This actually updated some grademax values in the grade_items table.    The ones that were modified which were a result of the change from SUM to Natural, were almost entirely caused by “drop the lowest” not being supported for that course/category
as the values of all the grade items didn’t match.   

Our solution for doing the upgrade and minimizing the affect of grades changing (even though it was just for about 1% of the courses), is to lock the grade scores, and provide guidance for faculty to contact help if they need to change grades after the fact.    In just a few courses, the grademax for the item might be different, thus a percent or letter might show up different, and we will do direct outreach to them.  We have a query to identify these courses.     We did have a few other scenarios where the grademax changes, just a handful.  Courses with calculations or courses with locked categories or course totals. 


Following are queries we run with a basic description -

######################

# create archived copies of the original values if you’d like - 

CREATE TABLE mdl_orig_grade_items  LIKE mdl_grade_items; 

INSERT mdl_orig_grade_items SELECT * FROM mdl_grade_items;


CREATE TABLE mdl_orig_grade_categories  LIKE mdl_grade_categories;

INSERT mdl_orig_grade_categories SELECT * FROM mdl_grade_categories;


CREATE TABLE mdl_orig_grade_grades  LIKE mdl_grade_grades; 

INSERT mdl_orig_grade_grades SELECT * FROM mdl_grade_grades;


######################

# lock grade_grades -
update mdl_grade_grades set locked=1, locktime = now();  

# reset the rawgrademax for items in grade grades - (grademax fix)
update mdl_grade_grades gg join mdl_grade_items gi on gg.itemid = gi.id set gg.rawgrademax = gi.grademax where gi.itemtype not in ('course','category');

# fix my clicker entries
update mdl_grade_items set itemtype='manual',itemmodule= NULL where itemmodule="iclicker";

# reset my sum of grades to clear the aggregateonlygraded flag - 
update  mdl_grade_categories set aggregateonlygraded = false where aggregation = 13; 




######
Other HANDY SQL 
This is a handy SQL command to audit your current setup for course totals -
######
select aggregation, aggregateonlygraded, depth, count(id) as c from mdl_grade_categories where depth = 1 group by aggregation, aggregateonlygraded,depth 

identify courses/categories  which have sum of grades, drop the lowest where grade items don’t have the same value and drop the lowest won’t be used.   
######

Select gi0.id as ctotid, gi0.courseid, gc2.id as gcid, gc2.aggregation as agg,
max(gi.grademax) as gmx1, min(gi.grademax) as gmx2,gi0.locked,
if(gi0.itemtype='category',concat(gi0.courseid,' ',gc2.fullname,' cat'),
 if(gi0.itemtype='course',concat(gi0.courseid,' ctot'),
 concat(gi0.courseid,' ',gi0.itemname))) as iname
From mdl_grade_items gi0
left join mdl_grade_categories gc2 on gc2.id = gi0.iteminstance
left join mdl_grade_items gi on gi.categoryid = gc2.id
where
gi0.calculation is null
and

gi0.itemtype in ('course','category')
and (gc2.droplow > 0 or gc2.keephigh > 0)
/* gi0.itemtype = 'course' */
and gc2.aggregation = 13
group by gi0.courseid, gi0.id
having gmx1 <> gmx2





####
in a nutshell, you can do an upgrade to 2.8, but to make it “cleaner”, at least on May 12, 2015,
I’d recommend that you do some additional SQL and add some patches.  
I think 2015 will be a rough year, but am confident the grade book will continue to improve and be easier to use and more intuitive. 


In reply to James Henestofel

Re: Upgrade from 2.6 to 2.8 course total not calculating grades correctly

by Bob Puffer -

Readers of this forum who are using or planning on using the 2.8 or 2.9 Moodle gradebook MUST BE AWARE of the discussion going on in https://tracker.moodle.org/browse/MDL-48618. The proposed solution for this issue from Moodle HQ is to allow different grademaxes for different students on the same grade item. I have talked to NOBODY who thinks this is a good solution (outside of Moodle HQ). The discussion in the tracker should actually be taking place in this forum but it is now to long to copy. Please go to the tracker item and register your dismay at this gigantic step backwards in usability of the Moodle gradebook.

In reply to James Henestofel

Re: Upgrade from 2.6 to 2.8 course total not calculating grades correctly

by Trevor Jones -
Picture of Core developers Picture of Plugin developers

Hi All,

I've been watching the progression of the tracker items regarding the different and competing causes of grade changes in the gradebook due to the upgrade to 2.8.

One of the discussions that I haven't seen is surrounding methodologies to guarantee past grade continuity. Thus far all the discussion is around either fixing individual causes of the currently identified issues via code in a future release of Moodle or minimizing the number of changes in cases where the changes can't be avoided (ie. Aggregation of subcategories).
These discussions also don't apply to the general issue of guaranteeing continuity year over year, eg. students, instructors, or admins inadvertently perform actions in a course after it's closed that cause a grade calculation to change after grades have been submitted. I know this discussion is specifically regarding the 2.6 -> 2.8 upgrade but I wanted to share our approach because it seems to address the issue at hand (at least in part).

The approach my institution is looking at for the general case of guaranteeing grade continuity (for courses that have already completed and should not have changes to grades occur) is to programatically lock the grade_items and grade_grades associated with the course after closure. This can be done quite simply via a sql statement such as:
update mdl_grade_items set locked=1 where [insert your course identifying criteria];
update mdl_grade_grades set locked=1 where [insert your course identifying criteria];
While this does not help with the above problem for 'live' courses, it does prevent changes to grades due to the upgrade in 'closed' courses according to my testing so far.

In regard to 'live' courses where the above solution is not applicable, we are taking the approach of:

  1. applying the patches from issues: MDL-48634, MDL-48618
  2. Identifying courses which experience grade changes despite the above patches and working with the instructors to modify their grade books in such a way that they are not impacted by the issue
  3. Custom approaches on a case by case basis where neither 1 or 2 is practical. (database backups, freezing a copy of the course, etc)

We are upgrading in two weeks so I'd love to hear about approaches used by other institutions regarding this subject. Or if you're aware of issues I'm not aware of with our current approach that would be very helpful as well.

Cheers


In reply to Trevor Jones

Re: Upgrade from 2.6 to 2.8 course total not calculating grades correctly

by Bob Puffer -

The tracker items covering the gradebook issues are numerous and complex. I don't think your reading of them is accurate. There is a desire to maintain continuity year to year but changes made by instructors AFTER the close of the gradebook term cannot be anticipated and probably should never occur anyway.

In reply to Bob Puffer

Re: Upgrade from 2.6 to 2.8 course total not calculating grades correctly

by Trevor Jones -
Picture of Core developers Picture of Plugin developers

Hi Bob,

I'm not sure I understand your reply.
I agree that there is a desire, by the institutions using Moodle, to maintain continuity but as we've seen given the issues linked above and the existence of this thread, changes can occur intentional or not. If, as you seem to agree, the grades in the gradebook of closed courses should almost never occur then the process I've described above is a nice safety layer that can be used to minimize impact of unexpected changes from future upgrades as well as accidental changes by instructors or students. 

For example, from my testing, after applying the locking across all closed courses, upgrading from 2.6.6 to 2.8.5 without any patches applied, showed 0 grade changes to any course in that set (~20,000 courses). Were other institutions practicing this procedure when they had upgraded to 2.8 I'd imagine the change of grades would have had less impact.

I'm certainly not saying this is the be all solution, but it is a possible administrative procedure to consider to mitigate future changes to grades, whether from user error or upgrade.

Cheers

In reply to Trevor Jones

Re: Upgrade from 2.6 to 2.8 course total not calculating grades correctly

by Damyon Wiese -
Hi Trevor, it is not as simple as locking grades. Locking grades only prevents their value from being changed in the database - but the grades in the database go through complex functions before they are displayed in the browser.

In the MDL-48618 example, the difference came from e.g. displaying a value out of the original max grade when it was graded, or the current max grade for the grade item. This resulted in different percentages etc, even though the DB was identical. This also means that scanning the DB to see if grades changed will not work (you would have to compare the user reports for every user to really find if there was any changes).

Anyway we are agreed to a policy decision (MDL-50432) that grades should not change on upgrade for any reason - and are resolved to finding a way to do this properly in future.

See: https://moodle.org/mod/forum/discuss.php?d=315409
and: https://tracker.moodle.org/browse/MDL-50522