As @swomma has described, occasionally (roughly once per month) a member creates an additional user account and re-enlists. This may be because they left a long time ago and can't remember their password, or forgot they had an account, or even to try and 'start fresh.'
v2 admin let you change the user associated with enlistments and assignments (and pretty much everything else). v3 doesn't let you do that, quite deliberately, because it could lead to data quality issues, apart from this particular use case.
A quick fix is to add the user field to the edit forms of resources like enlistments and assignments, but only when the user doing the editing has admin permission.
A more holistic solution is to create a "Merge Users" function to automate the process and record it more clearly in the audit trail.
In the meantime, these changes can only be made directly in the database.
As @swomma has described, occasionally (roughly once per month) a member creates an additional user account and re-enlists. This may be because they left a long time ago and can't remember their password, or forgot they had an account, or even to try and 'start fresh.'
v2 admin let you change the user associated with enlistments and assignments (and pretty much everything else). v3 doesn't let you do that, quite deliberately, because it could lead to data quality issues, apart from this particular use case.
A quick fix is to add the
userfield to the edit forms of resources like enlistments and assignments, but only when the user doing the editing hasadminpermission.A more holistic solution is to create a "Merge Users" function to automate the process and record it more clearly in the audit trail.
In the meantime, these changes can only be made directly in the database.