On the other hand I understand some ppl do want it anyway, the compromise could be to create a new function grade_allowed_value($min, $value, $max) then you would have to patch just one line of code, other benefit is it could properly deal with null == nice code in general.

The other place you may want to consolidate code is the aggregation types menu. If one wants to cut down the available choices, one needs to go to several places in the code.

} else if ($finalgrade > $this->grademax) { to } else if ($finalgrade > $this->grademax *2 ) {

Note that the code from MDL-12517 could be changed to a yes/no dialog box allowing a teacher to override the limits after a warning, rather than just prohibiting it. This is common in other gradebook programs that deal with exactly with the issue of this patch. Usually there is a maximum override factor (which could be set to 1) that can be set to keep teachers from getting carried away.

I am not recommending this feature for 1.9, but simply as a starting point in case this feature is demanded in the future. We have implemented it at our school, however, and it works fine.

/lib/grade/grade_item.php
change
if ($this->itemmodule != 'assignment' and ($rawmin != $this->grademin or $rawmax != $this->grademax)) {
$rawgrade = grade_grade::standardise_score($rawgrade, $rawmin, $rawmax, $this->grademin, $this->grademax);
to
if ($this->itemmodule != 'assignment' and ($rawmin != $this->grademin or $rawmax != $this->grademax*2)) {
$rawgrade = grade_grade::standardise_score($rawgrade, $rawmin, $rawmax, $this->grademin, $this->grademax*2);

change
return bounded_number($this->grademin, $rawgrade, $this->grademax);
to
return bounded_number($this->grademin, $rawgrade, $this->grademax*2);

change
if ($this->itemmodule != 'assignment' and ($rawmin != $this->grademin or $rawmax != $this->grademax*2)) {
$rawgrade = grade_grade::standardise_score($rawgrade, $rawmin, $rawmax, $this->grademin, $this->grademax*2);
to
if ($this->itemmodule != 'assignment' and ($rawmin != $this->grademin or $rawmax != $this->grademax*2)) { $rawgrade = grade_grade::standardise_score($rawgrade, $rawmin, $rawmax, $this->grademin, $this->grademax*2); change return (int)bounded_number(0, round($rawgrade+0.00001), $this->grademax); to return (int)bounded_number(0, round($rawgrade+0.00001), $this->grademax*2); change $grade->finalgrade = bounded_number($this->grademin, $finalgrade, $this->grademax*2); to $grade->finalgrade = bounded_number($this->grademin, $finalgrade, $this->grademax*2); change $result = bounded_number($this->grademin, $result, $this->grademax); to $result = bounded_number($this->grademin, $result, $this->grademax*2); /lib/grade/grade_grade.php change $finalgrade = grade_grade::standardise_score($agg_grade, 0, 1, $grade_items[$do]->grademin, $grade_items[$do]->grademax); to $finalgrade = grade_grade::standardise_score($agg_grade, 0, 1, $grade_items[$do]->grademin, $grade_items[$do]->grademax*2); change $finalgrade = bounded_number($grade_items[$do]->grademin, $finalgrade, $grade_items[$do]->grademax); to $finalgrade = bounded_number($grade_items[$do]->grademin, $finalgrade, $grade_items[$do]->grademax*2); /lib/grade/grade_category.php change $finalgrade = grade_grade::standardise_score($agg_grade, 0, 1, $this->grade_item->grademin, $this->grade_item->grademax); to $finalgrade = grade_grade::standardise_score($agg_grade, 0, 1, $this->grade_item->grademin, $this->grade_item->grademax*2); change grade->finalgrade = (float)bounded_number($this->grade_item->grademin, $finalgrade, $this->grade_item->grademax); $grade->finalgrade = (float)bounded_number($this->grade_item->grademin, $sum, $this->grade_item->grademax); to grade->finalgrade = (float)bounded_number($this->grade_item->grademin, $finalgrade, $this->grade_item->grademax*2); $grade->finalgrade = (float)bounded_number($this->grade_item->grademin, $sum, $this->grade_item->grademax*2); change $grade->finalgrade = (float)bounded_number($this->grade_item->grademin, $sum, $this->grade_item->grademax); to $grade->finalgrade = (float)bounded_number($this->grade_item->grademin, $sum, $this->grade_item->grademax*2); /lib/gradelib.php change $value = (int)bounded_number($grade_item->grademin, $value, $grade_item->grademax); to $value = (int)bounded_number($grade_item->grademin, $value, $grade_item->grademax*2); change $value = bounded_number($min, $value, $max); to $value = bounded_number($min, $value, $max *2); /grade/report/grader/lib.php change } else if ($finalgrade > $grade_item->grademax) { to } else if ($finalgrade > $grade_item->grademax*2) {

change
$gradeval = (int)bounded_number($grade->grade_item->grademin, $gradeval, $grade->grade_item->grademax); //just in case somebody changes scale
to
$gradeval = (int)bounded_number($grade->grade_item->grademin, $gradeval, $grade->grade_item->grademax*2); //just in case somebody changes scale

This was very easily doable in 1.8 and earlier - create a 100 point assignment and an X point assignment, put them in the same category with the X point one marked as extra credit, and presto - you could get 100+X points in a 100 point category. It seems not-at-all-doable in 1.9 - at least, in any practical way - unless I'm missing some magic incantation in the user interface.

Database changes are not allowed in 1.9.x branch, setting 2.0 as target.

What I'm doing for this quarter is that I've made the patches suggested above, and I'm using the "Mean of Grades (with extra credit)" weighting option (even though it's "unsupported"), which does basically exactly what I want with respect to mimicking the old behavior. Hopefully the solution in Moodle 2.0 will be cleaner.

/lib/grade/grade_category.php
change
$finalgrade = grade_grade::standardise_score($agg_grade, 0, 1, $this->grade_item->grademin, $this->grade_item->grademax);
to
$finalgrade = grade_grade::standardise_score($agg_grade, 0, 1, $this->grade_item->grademin, $this->grade_item->grademax*2);

will cause category and course totals to double when scores are manually updated.

Thanks for posting this patch. From visual inspection, it seems to have some good ideas.

Is it possible for either you or Nicholas to apply this to test.moodle.org? If so, I can make sure that it is thoroughly tested by myself, my colleagues, and those at other institutions to make sure that it meets everyone's needs and concerns.

--Gary

I did patch this on one of my development servers, although it would still be nice to have it on test.moodle.org so others can try it and so we can see how you and Nicholas would do it.

I was not able to get it to work for me. It kept setting my activities to the maximum grade.

I have written up three "use cases" to help you understand how people might use extra credit: http://docs.moodle.org/en/User_talk:Gary_Anderson/Examples_of_Extra_Credit_grading.

On an affirming note, your way with this patch of letting administrators select only certain types of grading strategies, if expanded, could go a long way to solve some of the usability issues. For example, I would probably start a new site with only "Simple Weighted Mean of Grades – unlimited", which I would call "Average of Points". Then, when someone wanted a weighted gradebook, I would add that. I suspect that many sites would not have teacher requests that go beyond two or three strategies, and if they did, that would be fine. Most teachers would be OK with methods being added if they knew that somebody was actually using it in their institution. Hence, this does not need to be a course based setting and instead one could simply have a set of instructions of how to configure Moodle to be as simple as possible for a given institution by turning off all unrequested features easily.

Is this going to be the way we do things?

I like the idea of administratively hiding aggregation methods and using these new aggregation methods to facilitate grades above maximum/100%.

If this is the way this will be implemented in the future, we will start incorporating these changes into our LSU grade book.

I went into the tutorial course that I have created on those sites and on the 100 point test I gave the first student 105, assuming that they got all the required answers right on the test and answered a 5 point optional question correctly.

On the patched gradebook, it still converted this score to 100.

Using my patched code given with this original bug report, it allowed for the 105 points. Note that had I given even more points, the course or category grades can also go over 100 percent, which is also what I would expect and what would certainly happen if I computed the grade by hand.

Using the LSU gradebook, it worked correctly and as I would expect.

Note also, that the patches that have been contributed, both by me and by Robert (and his LSU gradebook) require no new "aggregation types", and that they have been extensively field tested with hundreds of courses and teachers and thousands of students. It works just fine for the problem identified.

I don't mind the use of global $CFG variables for the purpose of site configuration, but why don't you just use it to apply my original patch and have this form of Extra credit be done with?

Here is a link to the test course I am using. You will see that some of the students have more than 100% as grade in categories and course total.

http://test.moodle.org/1.9/grade/report/grader/index.php?id=2

I'll try to figure out what you are doing with extra credit categories in the test course later today and see if it gets at the issue. From a quick look, it seems like you are using an "aggregation method" that already has an extra credit feature.

I would suggest that we use a much more simple set of courses for this discussion, three scenerios of which I describe here: http://docs.moodle.org/en/User_talk:Gary_Anderson/Examples_of_Extra_Credit_grading

http://test.moodle.org/1.9/grade/report/grader/index.php?id=9

http://test.moodle.org/1.9/grade/report/grader/index.php?id=10

And the first and last:
http://test.moodle.org/1.9/grade/report/grader/index.php?id=11

This solves ALL your problems. Please see the examples I have posted above, they are simple, clear, and they work.

It is relatively simple, you can either like this patch and help me push it into 1.9.5 or you can keep claiming that grades >100% are the only correct way (which annoys me and several other developers) and in that case it will not be implemented in official 1.9.x branch at all, sorry.

To Gary:
1/ the patch above does not solve problems with scale grades
2/ the patch above is changing parameters of standardise score, this is imo not needed and may give different results
3/ the patch does not deal with overriding of grades
4/ the patch breaks grading completely for my country (Czech Republic, located in the middle of Europe)- sorry we have different grading standards

To Elena:
1/ there are technical limitations of what can be done in stable branch, the main limitation is we must not add any new database fields - the new aggregation type was the only way which is possible in 1.9.x - nobody proposed any other possible solution that would make the aggregation maximums optional without the need of regrading everything after any change of settings
2/ the grades > 100% from activities are something we developers like even less than grades >100% in grade categories
3/ I expected that people will want the grades>100% from activities - I implemented a solution suitable for them - though only through direct modification of config.php because it can not be on for technical reasons

To anybody else:
1/ even if you do not like what the current patch does it should be much much easier now to tweak the maximums and minimums because you need to modify only one method now instead of hacking multiple moodle files in many different places

Petr

• input of new grades and
• calculation of final result from aggregation or calculation

Petr, can you explain exactly what the problems really are? I didn't really get it from the discussion so far.

I have looked at the three courses you put on earlier today and discussed thoughts on the jabber network with Martin and Tim (you and Petr were not on at the time).

Keeping in mind that my original patch and the feature in the LSU gradebook works with all aggregation types, does not require creating an separate assignment if extra credit is part of an single activity, requires no special training for teachers on gradebook configuration, and does not require new aggregation types, I think that we should stick with my original approach.

The only thing I would change in my existing code is to have the constant of 2 be set with a global $CFG variable. With a value of 1, everything works the same as it does now. I frankly don't like the idea of the code moving things to the boundaries when out of range as it masks data entry errors (which in practice are easy to spot if you do no boundary checking), but I guess we can live with that.

1. Grades can be set to any number up to $CFG->gradeoverhundredpercentmax
2. Category totals and course total are automatically updated and go over 100% if the correct aggregation method has been selected
3. You do not need to set up special grade items for extra credit
4. You can disable all the "original" aggregation types in favour of the unlimited ones, and you can even rename these in your custom lang file if you want

Bearing everyone's comments in mind, in a chat with Nicolas, Petr and Martin, the following solution was proposed:

• In Moodle 1.9.5, add an unlimited grade values setting in Administration > Grades > General settings to enable administrators to allow grades over 100% across the whole site. The setting will have a warning that enabling it will result in all grades being recalculated, and the possibility of a high server load.

• In Moodle 1.9.5, add a new aggregation types setting in Administration > Grades > Grade category settings to enable administrators to reduce the number of aggregation types.

( See also http://docs.moodle.org/en/Development:Gradebook_improvements_in_Moodle_1.9.5 )

• Consider adding 'unlimited' aggregration types for allowing category and course totals over 100% in Moodle 2.0. If you'd like this feature, please vote for MDL-18566.

As always, feedback on our proposed solution would be appreciated.

To put it another way, consider 2 cases, assuming for both that "allow grades over 100% across the whole site" is turned on:

1. I have a category that is a "mean of grades (with extra credits)" aggregation. I have 2 items in there, both of which are worth 10 points, and one of which is extra credit (with an extra credit value of 1.0). I award a student 10 points on one item and 1 point on the other.

2. I have a category that is a "mean of grades" aggregation. I have 2 items in there, worth 10 points each. I award a student 12 points on one item and 10 points on the other.

In both these cases, the category grade should be 110%. Is that what would happen with the new changes, or would the grades be different in these two cases? Is the second case even possible with these changes? (would it still be possible to award 120% in the second case if the assignments were worth 100 points instead of 10, requiring 120 points to be awarded? will the pop-up menu allow me to award 120 points? 200 points?)

Thanks for any clarification!

Looking back at my notes, when I made this patch, I simply looked at all cases where bounded_number was found. Of the 11 cases, these 7 were the ones that needed to be adjusted. I used '2' as the factor because I reasoned that in practice, optional work was typically only a fraction of required work, and I could not see anyone wanting to more than double the number of points on an activity in most cases. In practice, placing no limit would also have been OK as teachers are always looking a their gradebook for anomalies, especially before assigning grades. In fact, moving excessive grades to a boundary only masks data-input errors.

So, what I want to better understand by looking at the fix is:

1. If all 7 of the above patches are not needed, which ones are?
2. Why is any <b>other</b> code needing to be patched to address just this issue?
3. Why the big warning about grades needing to be recalculated? Certainly just turning on this patch would not need it. Turning it on does not change any scores or other database values.
4. When turning off the patch, recalculation may or may not be needed; it depends on how it is implemented and this needs testing. Ideally, no database changes would be made when turning off this feature either. Only the computation and display would change.
5. Is the lower bound also going to be eliminated (thus allowing negative grades)? If so, this needs careful testing as it is not something I anticipated in this patch.

As I told Martin D., if this is implemented, I will write a tutorial on how it works which can be the common starting point for people wanting to do extra credit (like my tutorial on weighted grades). Note that this patch does not solve all extra credit problem. For example, before 1.9, individual activities could be identified as "extra credit"; this still does not address that issue. But it is a step to allow for one accepted way of accounting of optional points withing an activity, and at least one way for whole categories, to be factored into a course grade in practice.

--Gary

1. the only patch needed is Petr's patch currently attached to this issue.
2. I don't understand your question, the grammar escapes me
3. We need to recalculate because each category is represented by a grade item, which holds its own grade (based on aggregated grade items) in the DB, and can be overridden etc. When the overgrading option is turned off, it caps to the category grade item's grademax. When you switch it on, the category's grade needs updating. Simple
4. See 3.
5. grademin is still used as before, but it could also be overridden with a little more coding to Petr's patch. Not requested much yet.

You say that Petr's patch doesn't allow for items to be identified as extra credit. That needs qualifying. I have set up several items (assignments, quizzes) as extra credit on the test server and it works just fine. Please explain.

I do like the idea of being able to reduce the number of aggregation types that a site uses as that reduces complexity for teachers (I hope it is documented in a way that suggests that types can be enabled as teachers request them). I just think the feature should be treated separately so that this patch can be evaluated on its own.

I am not convinced that recalculations are needed to turn this patch on. I am concerned about the consequences of turning it off if you recalculate grades. A site administrator, in the process of playing with this setting, might be destroying all the over 100% data for every course at once – or maybe it is just how the grade is displayed. My original patch does not recalculate grades; doing so should involve careful testing, IMO.

This will take me a few days to test.

We'll only be adding 'unlimited' aggregation types to Moodle 2.0 if a reasonable number of people want them.

Regarding documenting reducing the number of aggregation types, I've added the following text to http://docs.moodle.org/en/Development:Gradebook_improvements_in_Moodle_1.9.5:

A new aggregation types setting in Administration > Grades > Grade category settings enables administrators to reduce the number of aggregation types.

By default, all existing aggregation types are available (Mean of grades, Weighted mean of grades, Simple weighted mean of grades, Mean of grades (with extra credits), Median of grades, Lowest grade, Highest grade, Mode of grades, Sum of grades). This list may be reduced to only a few types, with additional types being enabled as/when teachers request them.

Please feel free to edit the page to make things clearer.

Yes, category totals can go over 100% if unlimited grade values is enabled.

I've just tried your two cases on our 1.9 test site http://test.moodle.org/1.9/ (username teacher, password testm00dle) and obtained a category total of 110% in both cases. Please feel free to test further cases.

Enabling unlimited grade values removes the maximum grade check when teachers add grades directly in the gradebook. When teachers add grades from within assignments, they can only select the maximum grade or less.

Instructions for this variable setting can be part of the extra-credit tutorial in the docs. Given the resistance of Petr and Nicholas to allowing any extra credit that might lead to values exceeding 100%, it seems like a $CFG variable would be a good way to go.

Since grades are not recomputed, removing the variable or setting it to 1 does not alter entered data which I would be really concerned about with Petr's last patch.

And these settings have been working fine for us for over a year and the LSU gradebook does a similar thing so at this point I am I have pretty good confidence it is a good solution, but I am open to seeing examples of where this presents a problem.

I read on that page you are worried about people switching grades > 100% off temporarily and loosing info, that would happen only for manually overridden grades with > 100%. There are many other ways to loose grades like changing scales, editing grade items, etc. General solution for this type of problems is to specify these values in config.php, maybe we could just add this basic info into setting help

Showing rows 0 - 0 (1 total, Query took 5.0248 sec)

SELECT DISTINCT go.userid
FROM mdl_19_grade_grades go
JOIN mdl_19_grade_items gi ON gi.id = go.itemid
LEFT OUTER JOIN mdl_19_grade_grades g
ON ( g.userid = go.userid AND g.itemid =1799 )
WHERE gi.id <>1799 AND g.id IS NULL ;

Five seconds for one user id item is way too expensive! If we can optimize this query then I think we would see lots of improvement.

The above query has an unnecessary table join to grade_items gi. I run and equivilent query removing the unnecessary grade_items join and replaced the gi.id <> 1799 with go.itemid <> 1799. The equivilent query is consistently 0.34 second instead of 5 sectonds. If we can replace this in the code as a patch I think will help.

SELECT DISTINCT go.userid
FROM mdl_19_grade_grades go
LEFT OUTER JOIN mdl_19_grade_grades g
ON ( g.userid = go.userid AND g.itemid =1799 )
WHERE go.itemid <>1799 AND g.id IS NULL;

The query is from lib/grade/grade_item.php

1615 // precreate grades - we need them to exist
1616 $sql = "SELECT DISTINCT go.userid
1617 FROM {$CFG->prefix}grade_grades go
1618 JOIN {$CFG->prefix}grade_items gi
1619 ON gi.id = go.itemid
1620 LEFT OUTER JOIN {$CFG->prefix}grade_grades g
1621 ON (g.userid = go.userid AND g.itemid = $this->id)
1622 WHERE gi.id <> $this->id AND g.id IS NULL";

new query should offer a slight improvement over the existing one.

1615 // precreate grades - we need them to exist
1616 $sql = "SELECT DISTINCT go.userid
1617 FROM {$CFG->prefix}grade_grades go
1618 LEFT OUTER JOIN {$CFG->prefix}grade_grades g
1619 ON (g.userid = go.userid AND g.itemid = $this->id)
1620 WHERE go.itemid <> $this->id AND g.id IS NULL";