Some administrator in jira made the following mistake, amplified by a bug in JIRA I believe (or 2).
Assumption: username of admin if peter, it's an account in a delegated user directory (AD).
1) Peter logs in to JIRA, goes to user management
2) Peter creates an INTERNAL user with username (also) peter. ( by mistake, but jira doesn't warn him or block this action).
3) Peter gets logged out because this new internal peter overwrites his own account
4) Another admin logs in and sees the new *internal* peter account.
5) Upon viewing this user, JIRA tells us there are duplicate accounts (no kidding, but better late than never).
6) Admin changes the username of the new peter account to 'peter_new'.
7) Now the old peter account from the delegated directory shows up in the list of users again. All good?!?!?
8) No! JIRA has connected every single action and issue from the 'peter' account to the 'peter_new' account. So peter_new is suddenly the reporter of thousands of issues from years ago, also peter_new is the assignee of open issues. All comments seem to be made by peter_new.
I did create a support ticket, but response is slow.
Is there any easy way I can move back all issues, comments, etc to the original 'peter' user? Some SQL probably?
In case this helps anyone else, we wound up having the EXACT same situation occur, and experienced the exact same problem. The fix is actually pretty easy! Here's what we did.
When the local, duplicate username account was created, what happened in the app_user table of the database is that the user_key field, which usually has the person's username, switched to the user ID for the pre-existing user. So instead of john.smith, it displayed ID12345 in the user_key field in the app_user table. And the new user that was created had the username (ex, john.smith) in the user_key field.
We started up Jira and everything looked great! The only thing you might have to correct is that any actions or assignments that were done while the problem existed will show ID12345 for the user instead of the owner of the username. You can just update/reassign those to be the real john.smith afterward,
You can connect multiple user directories to Jira Server. However when the same username exists in multiple directories, only the user account in the top ordered directory in JIRA is the one that is able to login to JIRA. That is the first fact you need to be aware of.
Second, when you rename a user account in Jira, or in a LDAP directory that is syncing to Jira, Jira is trying to be helpful and in turn will track these user account renames in order to make sure your account still has all the previous history, etc.
You might be able to fix this via SQL, but the easier solution is to go back to the peter_new account and just rename it again back to peter. Then delete that account in the internal directory. Provided that your LDAP directory still has the old 'peter' account still there, then after that internal account is deleted from the Jira internal directory, the next time peter tries to login, it will use the credentials form the other user directory (LDAP).
Right now your cwd_user directory has likely two different entries for peter. But each account there has a different directory_id to show that it originates from a different user directory. But I wouldn't typically recommend hacking away at SQL to fix this, at least not without knowing a lot more of the details here.
I would recommend that you create a backup of you database before you try any changes like this though just to be safe.
Thanks, but JIRA won't let me rename the peter_new to peter. It tells me there already is a user with name peter.
Why isn't JIRA performing this check when new users are created?
BTW The support team sent me some SQL queries, which didn't not work but I managed to solve it myself. All that was needed was a litlle fiddling with the app_user table (so it seems).
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events