Unable to autocomplete some usernames in Jira
プラットフォームについて: Server および Data Center のみ。この記事は、Server および Data Center プラットフォームのアトラシアン製品にのみ適用されます。
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Fisheye および Crucible は除く
要約
When typing usernames in Jira fields like Assignee, Reporter or @mentioning users in comments, some usernames will show up in autocomplete and others will constantly fail to.
In the browser's console we may see errors like:
"Exception: Uncaught TypeError: Cannot read properties of undefined (reading 'issues')"
環境
All versions of Jira 8.x.
診断
You may observe this behavior for what seems to be all usernames or just some, while others work.
1) Log evidence
While reproducing the issue, watch Jira's atlassian-jira-log for a similar message:
2022-01-13 13:47:25,668-0500 https-jsse-nio-443-exec-178 url: /rest/api/1.0/users/picker; user: redacted-username ERROR redacted-username 827x22791155x2 5ub999 192.168.0.1 /rest/api/1.0/users/picker [c.a.p.r.c.error.jersey.ThrowableExceptionMapper] Uncaught exception thrown by REST service: User 'some-jira-user' has no unique key mapping.
The key is the "has no unique key mapping":
$ cat application-logs/atlassian-jira.log | egrep -o "User '.*?' has no unique key mapping" | sort | uniq -c
62 User 'some-jira-user' has no unique key mapping
2) Database evidence
For each username that's returned in the grep
above, check if they have the same lower_user_name in both tables below or if in one of them, there's a trailing #1 or other number:
select * from app_user where lower(lower_user_name) like '%some-jira-user%';
select * from cwd_user where lower(lower_user_name) like '%some-jira-user%';
原因
If both the log and database evidences above are confirmed, it means Jira has lost consistency of this user's record. The lower_user_name
of both tables app_user
and cwd_user
should always match.
Among possible root causes are:
- The user was renamed at some point and the change synced into Jira. Even if the change was reverted in the underlying User Directory, Jira wasn't able to recover on it's own
- Some duplicate username came in through the User Directory sync. Even if the duplicate was soon fixed, Jira wasn't able to figure out on it's own on further syncs.
- There were changes on key attributes to Jira in the User Directory, like a user's
objectGUID
orsAMAccountName
and Jira wasn't able to resolve the conflict.
In all these situations, we'll see #1 or other numbers appended to usernames in Jira's database.
ソリューション
1) Full directory sync
The first advised approach is to force a full directory sync. You may trigger it by editing the LDAP directory, saving it without any changes and press the resync button.
Jira will understand the directory's been recently edited and will force a full sync instead of trying an incremental one.
If the issue persists, try the next solution.
2) Manual intervention
We may manually fix the DB records with the following steps — though it requires some downtime. We also advise following the steps in a non-production instance first to validate it to your scenario and get used to the commands:
1) Stop Jira (if DC, stop all nodes)
2) Backup Jira's database to be used in a rollback/backout if needed
3) Update the mismatched record(s). The example's for username "some-jira-user#1":
update app_user set lower_user_name = 'some-jira-user' where lower_user_name = 'some-jira-user#1';
4) Commit the DB changes and start Jira
Confirm if usernames show up when autocompleting and there are no other similar evidences in the logs.
After fixing a username, others may show up in the logs when searching/autocompleting a username. Repeat the Diagnosis and Resolution steps for each.