Hi Everyone.

We are planning to change the default behaviour when a user is reassigned to a certification in Totara 2.5 and above, and would like to seek feedback from those who may be affected by these changes.

Until now, when a user is removed from a certification and reassigned, their completion data has been (mostly) reset. There are certain caveats to this behaviour, but in general the user will appear to be moved back onto the primary certification path and will be required to complete the primary certification path courses to become certified. We consider this "resetting" to be a side-effect, rather than the intended outcome. We've also had numerous reports where subscribers and partners have requested we change the current behaviour.

The behaviour we are proposing, which we are planning to implement in existing released branches of Totara, is to restore the state of users when they are reassigned. This would be the desired behaviour in situations where a user was accidentally removed from a certification, such as if they fell out of membership of a dynamic audience and later rejoined, some mistake was made in the assignments interface, or the user was incorrectly removed from a certification due to a bug.

In the past, we considered making this change, but we ended up deciding that we had to leave it as it currently is because we didn't want to remove an existing behaviour that some clients might be depending on. We created the Certification Reassignment Restoration tool, which allows administrators to restore the state of users, but with certain conditions (such as that the users had not already made some progress since being reassigned). Some big drawbacks of the tool are that it is not always obvious when a user has been reassigned, users might not know that the tool needs to be used, and it could be too late when the need is realised. Or worse, some clients may not even know about it or might incorrectly assume that reassigning will restore the previous state.

Ultimately, it leaves those with a need to restore users no clean way to do so. 

We believe that some users may have been (and possibly still are) deliberately unassigning and reassigning users in order to reset the user's data. In addition to changing the path, it allows the certification administrators to alter the due date - one of the restrictions of certifications is that due dates can only be moved forward in time, not backwards, and this set of actions provides a workaround. A major flaw to this approach is that if the user is assigned through a group assignment (such as an audience assignment) then the whole group needs to be removed to be able to remove the single user, thus all users in the group will be affected.

There are several reasons for re-considering our previous decision.

1. The new certification completion editor, being released in Totara 2.5 and above in February. Click here for details. This tool will allow certification administrators to change the state of a user, such as moving them from "certified" to "assigned", or changing their due date backwards (or removing it completely). We consider the editor to be the "correct" way to make these changes, rather than relying on the "side-effect" of reassigning. Clients who were previously depending on reassignment as a means of resetting the state of users will now have an alternate method of achieving the same goal, but in a much safer and controlled way, without unforeseen side-effects.
2. We've now learnt that reassigning users is inconsistent, depending on the prior state of the user's completion. If a user was certified but the window had not opened, their existing course completion records may re-trigger certification (but depends on the setup of the certification paths, whether they contain the same courses or not). If a user was certified but their recertification window had opened, they would end up back at the start of the certification process. Generally, it's not obvious what the outcome will be.
3. Finally, we have become aware of a bug when reassigning. If a user's recertification window had not opened at the time they were unassigned, they could end up in a state where they are neither certified or not, possibly preventing the user from completing the primary certification and from becoming certified.

Our solution is to automatically restore users to the state that they were in before they were unassigned. This can be achieved by using the certification completion history data which is recorded when a user is unassigned. For a user who is unassigned and immediately reassigned, we want it to appear as if nothing has occurred. If some other change is desired then the certification completion editor should be used to make that change. If some time has passed between the user being unassigned and reassigned, then any events which should have occurred during that time, such as recertification window opening or expiry, will be processed by cron (as if their execution had just been delayed).

With this change in place, and with the new certification completion editor available, we could retire the Certification Reassignment Restoration tool.

We'd like to get some feedback on this change. If you are currently unassigning and reassigning users in order to achieve a specific goal (such as change of state or changing due date) then please give us details. If you've been using the Certification Reassignment Restoration tool then let us know. If you weren't aware that reassigning users was not restoring their state then please tell us.
Likewise, if you have any thoughts on this behaviour change, either for or against, please do let us know. 

Nathan