2.1.6, 2.2.3, 2.3
MOODLE_21_STABLE, MOODLE_22_STABLE, MOODLE_23_STABLE
This was created based on
It has been noticed that, due to moodle inconsistencies, one backup can end with something like this (numbers are example ids):
A- only users 3 & 4 appear as enrolled (course/enrolments.xml).
B- only users 2, 3 & 4 are included in backup (users.xml).
C- there are grade_grade for users 1, 2, 3, 4 & 5 (gradebook.xml).
A-C: Non-enrolled users having gradebook information. This is being handled by MDL-33505
B-C: Missing users in backup having gradebook (or course completion information). This issue.
From a pure backup perspective, what is happening is that both the gradebook and course completion information is being included in backup AFTER the users have been written. Note this is (logical) correct as far as neither gradebook nor course completion should be adding new users to the backup, because all them should have been already captured (annotated) by activity, enrollments... but it has been demonstrated that there are inconsistencies like the A-C above, leading to missing users in the backup file.
So, no matter if later those users are restored or no, to be 100% consistent backup should include the information of ANY user found in the whole process (the only on-purpose exception to this are logs, but that's another history).
So we are going to change a bit the order of execution of steps in the backup_final_task (the one in charge of generating the gradebook, course completion and users), so users will include always those detected when generating the gradebook and course completion information. That way backup will be consistent and there won't be "orphan" userids at all.
As said, this does not try to fix the A-C inconsistency nor how this is handled on restore. It's only one change to avoid one inconsistency in generated backup files. Nothing else.