JIRA created duplicate user and has moved all users to the new user

Isaac_nl December 1, 2017

Hi,

 

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?

4 answers

1 accepted

0 votes
Answer accepted
Peter October 16, 2019

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 stopped Jira, deleted the new (duplicate) user row from the app_user table
  • Then we deleted the corresponding row for that new user from the cwd_user table
  • Finally, we updated the user_key field for the original john.smith user in the app_user table to hold the username instead of the key again (in other words, we changed the user_key field for the original owner of that user from ID12345 back to john.smith).

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,

Isaac_nl May 4, 2021

What a coincidence you're named Peter ...

Like # people like this
0 votes
Sibel Avcı Sehlikoglu January 17, 2022

in my case

curl -X GET "https://jira.myexample.com/rest/api/2/user/duplicated/list" -u username

there is no duplicated user reported .

But I still have duplicated user error at integrity checker tool

0 votes
Isaac_nl December 4, 2017
0 votes
Andy Heinzer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
December 1, 2017

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.

Isaac_nl December 3, 2017

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).

Theodore Knab December 14, 2021

Can you post the sql for this ?

Peter December 14, 2021

Look above - I didn't post the SQL but I posted the exact steps you need to take. It would take only a few very basic SQL commands.

Like Theodore Knab likes this
Theodore Knab December 14, 2021

I discovered we have a duplicate on our machine 

Used this command to find the duplicate:

curl -X GET "https://jira.myexample.com/rest/api/2/user/duplicated/list" -u myuser

Enter host password for user 'myuser':
{"duser":[{"directoryId":10001,"directoryName":"Delegated LDAP Authentication","userActive":true},{"directoryId":1,"directoryName":"Jira Internal Directory","userActive":true}]}

 

Verified in SQL:

The SQL to find dups in MySQL:

 

MySQL [jira]> select id,user_name, directory_id, display_name, email_address from cwd_user where user_name = 'duser';
+-------+-----------+--------------+---------------+----------------------------+
| id | user_name | directory_id | display_name | email_address |
+-------+-----------+--------------+---------------+----------------------------+
| 11300 | duser | 10001 | Dave User | duser@example.net |
| 14900 | duser | 1 | David User | duser@example.net |
+-------+-----------+--------------+---------------+----------------------------+

 

Not sure the best way to fix this. I don't think the solution above will work for us. All the history is in the newer account. 

 

Suggest an answer

Log in or Sign up to answer