Best practice forum (Archived)
This forum discussion has been removed
You should be able to update usernames using the ID number - we do this regularly. What errors messages are you seeing?
Cheers,
Ryan
I had this exact issue. The solution that worked for me was to use the bulk user update tool instead of HR Import because as you noted, you can't edit the ID number through HR Import. The file formats are pretty similar so you shouldn't have to change much in your file to make the necessary updates.
Ah, I see your issue. I think the problem here is that either way you need an immutable ID to ensure consistency. Given that you can manually amend the ID number in the profiles it's not truly immutable. If you want to update it you'd need to use something else.
Perhaps there should be an option to update users based on their 'user id' (i.e. from in mdl_user) as this is system generated and can never change.
Hi guys,
The ID Number is created by the admin, its changeable via sync. The actual unique identifier is the User ID which is created by the system, you can export a report which has a User ID column. The only problems I can see is if you try to change the ID number to one which already exists in the system. Its very likely Im misunderstanding something here - Id be grateful for any further explanation!
cheers,
George.
Hi George
Unless I'm mistaken, sync uses 'ID number' as the key (not user id). You can update it via the front end but not through sync.
Cheers,
Ryan
Hi Ryan,
You're quite right, as I found out. Changing the Username is straightforward enough. Ive had a bit of chat with our senior devs and the issue here is the immutability of the ID Number - its absolutely integral to the functionality of sync, so any changes, as discussed above, would require a major re-write.
There were also some serious concerns about the reliability of changing the unique identifier like this, in terms of best practice any changes to the unique identifier would have to be made manually & simultaneously in the external system & Totara.
regards,
George.
+1 on this.
Maybe George can help us create a feature request ticket on bug tracker?
This is a big pain point for us as well. For us, the problem is that our Totara's "ID number" is based on our HR system's ldap, which links to user's email address. However, our users can change their ldap (or email address) at will (without notifying HR I think).
So for example, we have several cases in the past that the user, let's say, used to have ldap / username (also in sync with Totara's Optional field "ID number"), say, chuang. Based on this username, he was assigned with several trainings based on the dynamic audience rulesets. However, one month later, the user decided to change his ldap (on our HR system) and email address, from, say, chuang@example.com, to bigbear@example.com. Totara will then create another new LMS account for this user, and the user will lose all of his previous training assignments and RoL. Currently we have a workaround (to manually "delete" the "new" account, then change the email address on the old account with the correct training assignments and RoL), but it's just not ideal.
I'm sure that there should be a more elegant solution for this. Thanks!
Hi folks,
We have an existing feature request for this functionality ref TL-5892, it has been deemed high priority and is under consideration for development by Totara core.
This does not indicate a delivery commitment. Development of the functionality is subject to further prioritization and resource availability.
regards,
George.