We had an internal user directory, then a while later we enabled the LDAP integration. For some users, we used their domain user ID as their JIRA login, so moving to LDAP was easy. For other users, we used their e-mail address as their JIRA login.
If we rename a user's internal account to match their domain user ID before they log in for the first time using LDAP, then when they login to Jira, JIRA does some magic and links/merges the accounts so that they can login using their domain user ID (LDAP) and still see all their old issues assigned to them (to the new LDAP account).
However, if they login with their domain account before we've renamed their internal account to match the domain one, no merging happens. They end up with 2 separate user IDs, with separate issues.
I've been looking to see if I can recreate the merging, but I'm missing something somewhere.
Both user IDs are in cwd_user, and I think it does the merging/mapping using app_user, since this table changes when you rename a user through the Jira UI, and it appears to follow a logic where it appends "#n" to the end of the lowercase user ID, so JIRA 'knows' they are all for one human.
user_key contains the userID from app_user or an internally-generated id for this table, and lower_user_name contains the userID that this user_key maps to. For users with multiple accounts, lower_user_name contains the userID suffixed with "#1", "#2" etc. It makes sense to me that if a user had an internal account, then they get another account using LDAP, that it's this table that allows the issues assigned to their internal accounts to be 'merged' or seen as being for the same userID when they login using LDAP.
But in the cases where the user logged in using LDAP before we had renamed their internal account ID to match it, if I update app_user to append the next sequential number to the user id, this doesn't make JIRA display all the issue records when that user logs in, so there's obviously some other entry elsewhere which I'm missing.
e.g. if we have two entries in app_user
user_key="firstname.lastname@example.org" and lower_user_name="bill1"
user_key="bill1" and lower_user_name="bill1#1"
I would expect (from my logic) that logging in with LDAP account "bill1", the user sees issues associated with both accounts. But this doesn't happen. Is there another table containing details used to 'merge' the userIDs?
I've found some useful info which says "JIRA Administrators can now edit any username in the JIRA Internal Directory (this is often referred to as the "rename user" feature). This ability is important to have when you connect JIRA to an LDAP directory and the username format is different. Now you can edit the usernames before you connect to your LDAP directory and have them match in JIRA."
So my question could be "how do I match the user if we don't change the internal username to match the LDAP username before the user logs in with LDAP?"
Return of the editor following the opening of a ticket :
In regards to the behavior that you encountered, it is likely to happen when user renaming happens in which if we rename a user to an existing username but coming from another directory. This has been reported as a Bug and there is a clear explanation on how it happens from this comment
JIRA stores the details for user renaming at the app_user table hence, to get the information for the mentioned user, we can use the following SQL Query:
select * from app_user where lower_user_name = 'toto' or user_key = 'toto';select * from app_user where lower_user_name = 'email@example.com#1' or user_key = 'p.toto@@adressmail.fr#1;
Let us get the result above to check to which user the issue should map to.
the incident is solved
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs