MDL-50432 for the policy issue about this.
We agreed there that we should "never" change existing grades on upgrade, even if they are completely wrong.
So this issue is about creating a way to do this. It will require architecture changes in the gradebook - so it will be unlikely to be backported.
Some suggested ways to do this:
- Create an API to "freeze" a gradebook (both student and teacher views) by duplicating all the grade_grade, grade_item and grade_category data at that point in time. Create a new read-only report that only reads from the snapshot. Until the teacher accepts a prompt - all gradebook reports will only show this read-only snapshot.
- Create an API to support "versions" of the gradebook engine (both aggregation and display calculations). Never allow upgrade scripts to modify the gradebook DB. On upgrade, the teachers will be notified that there is a newer gradebook engine available if they want to use it. They still have the option of using the older engine.
- Store the "display" value for all grades in the DB instead of calculating it when the reports are viewed. Never allow upgrade scripts to modify the gradebook DB. After an upgrade, any action that triggers a regrading could cause changes to grades.