Grade overrides in gradebook

[eabbey]

We have used the merge users plugin for a while (since it was a report). We just noticed that it is not merging grades within a gradebook in a course when both of the student accounts were enrolled, and when the grade was an override (or, manually inputted from the gradebook instead of from the assignment view). It DOES merge grades as intended when the grades are not overrides and instead were entered from the assignment view.

We are on Moodle version 3.5.0. There are no errors or anything within debugging to indicate that something is wrong that I can see.

This issue is not related to https://github.com/ndunand/moodle-tool_mergeusers/issues/93. We have had that issue in the past, caused by conflicting statuses for completion activity, which I usually solve by deleting one in the database and then running the merge again. This issue is different from what I can tell.

• Is this the intended outcome? I might have missed that the plugin always did this in the past, and just thought it was merging them. I attempted to rollback the plugin, and that made no difference.

• Right now, our log output for a merge shows these two lines related to grades: DELETE FROM mdl_grade_grades WHERE id IN (38548, 38547, 38549) UPDATE mdl_grade_grades_history SET userid = '9232' WHERE id IN (137943, 137944, 137945, 137946)

Do I have a setting incorrect? I have been leaving the default settings for the plugin, as they have worked for me in the past.

Thank you

[jpahullo]

Thanks for reporting and for being using this plugin for such a long time!

It is something strange. It is not at all an expected result. I can see the case from your description, and it is unknown by us.

Thanks also for having done the work to clarify that this is not related to that of the completion status.

By now, from our process and detailed on the REAME:

Special Case #1: The grade_grades table has a compound unique key on userid and itemid. This prevents a simple update statement if the two users have done the same activity. What this script does is determine which activities have been completed by both users and delete the entry for the old user from this table. Data is not lost because a duplicate entry can be found in the grade_grades_history table, which is correctly updated by the regular processing of the script.

So the behaviour shown by your log is correct and as expected as it could be. But, maybe your understanding on "merging grades" is a bit different from what the plugin actually does. I mean, you do not expect to have one mark from a user and another one from the other student, and coexist both, since, as the README text says, only the marks from the kept user will remain (and marks from the user to move, will be removed).

Maybe does this process not match with your expectations?

About why dealing grade_grades this way, I remember that a discussion give us the feedback that this was the best option. Do you agree?

@ndunand, what do you think?

Thank you all for your time!

[eabbey]

In response:

We do have teachers who grade solely from the gradebook view instead of the assignment view, mainly because the course includes grades from a variety of different sources within the course, and the gradebook provides the opportunity for a teacher to grade all at once. So if Account A had a 10/10 for an assignment entered via the gradebook and Account B had no grade, and we merge Account A into Account B, we would want the 10/10 to appear in the gradebook for Account B.

In the scenario where Account A has a 10/10 and Account B has an 8/10, I understand the logic of keeping the 8/10, since we have to make a decision somewhere to make the utility work. So, my expectation would not be that two separate marks (grades) would coexist after the merge. But on the other hand, my expectation would be that a grade would be merged if there was no separate mark in the kept account.

[jpahullo]

Thanks for your sharings.

To rephrase your proposal, for any item graded merging user A (removed) into user B (kept):

• In case of single mark from both users, just keep the existing mark (either from A or B).
• In case both users have mark, keep the mark of the user B.

Is that right?

However, this brings to light other possibilities, like a "positive" behavior from this plugin: "keep the highest mark" from users A and B. Even considering this case, I'm sure there would be marks that lays out of the "scope" of these "behaviours".

What would be the whole map of possibilities or "behaviours" when merging grades?

At least, by now, there would be these 3 "behaviours" when merging grades:

A) The "current" behaviour (per user basis), explained on the README file: marks from user A are removed, marks from user B are kept. B) The "non-empty" behaviour (per item basis): if an item is graded for a single user, plugin must keep it; in case both users have mark for a single item, only B's marks are kept. C) The "positive" behaviour (per item basis): like "non-empty", but when both users have marks on the same items, the highest mark are kept.

It would be better to have a whole map of "behaviours" to consider, if they have to be considered.

Thanks for sharing and your time!

[eabbey]

I think this summarizes it very well. I would argue that there wouldn't be any other behaviors worth considering.

I would push for B as being the most logistical from an instructional standpoint. I don't know if it is the best from a programming standpoint or not. I think A misses out on what the merge is intended to do and C gets too complicated to work out.

[jpahullo]

Ok.

So let's open a time for developing these 3 behaviours and open PRs to solve it.

From a programming point of view, if we use some kind of dependency injection, it would rather be simple to face it for choosing which behaviour is running every time. I do not know how easy or difficult could be to face options B and C, since I do not know if they would need some post-process to make Moodle realize of those changes or any information is missed or cut the link from the grade item to the corresponding activity. I expect no problem when facing manual items added directly on the gradebook.

Any volunteer?

[jpahullo]

Re-reading it, I think it's an improvement of what the plugin does. Still, no PR for this issue I think.