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.
######
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.