Status: Closed (View Workflow)
Affects Version/s: 6.1.4, 6.2.7, 6.3, 6.3.15, 6.4-OD-13, 6.4.11, 6.4.14, 7.1.0-OD-04, 7.6.0, 7.13.0, 8.0.0
Fix Version/s: 8.4.0
Introduced in Version:6.01
Support reference count:29
Symptom Severity:Severity 3 - Minor
Bug Fix Policy:
Recently we had to change the usernames of our user directory, so I upgraded JIRA from 6.0 to 6.1.4 to get the new feature.
To put it briefly, I have set up and run a script that invoked the JIRA 6.1.4 REST API and changed the usernames from format A to format B.
Everything worked correctly and the JIRA web UI was OK, but then we had a huge problem with our integration scripts because the REST API started expanding the worklogs author incorrectly.
For instance, the following REST resources:
expanded worklog authors as follows:
which is wrong and unexpected.
I did some investigation on the database and came out with the following observations:
- Assumption (correct me if I'm wrong): The app_user table contains the mapping between user keys and lowercase user names and should be the source of information in JIRA to find a user by user key or vice versa. This is particularly true since there are unique constraints for each of the fields.
- Looking at the table data after the renaming, the app_user table has a somewhat mixed situation (maybe because our JIRA was upgraded since 4.4 to 5.0, 6.0 and now to 6.1) where almost all entries have the structure (id=progressive number, user_key=old username in format A, lower_user_name=new username in format B); only a few entries have user_key matched to the id and not to a username.
- Now, the worklog table has the author column populated with username in format A, so matching the user_key as I expect, and the same holds for jiraissue, project, etc... everything in the database relates to user_key
It seemed clear to me that there is a bug in the REST API implementation of the worklog object expansion, which seems to be unaware of the user_key attribute. Seems like it's not looking up the app_user table at all.
Another "proof" comes from the JSON response of
in which the users related to the issue object are expanded correctly (reporter, assignee) but the users expanded in the worklogs are not.
After issuing a question on Atlassian Answers I decided to do a brute-force "fix" at the database level, realigning user keys with user names, as reported in the link itself, and the problem of the user expansion in worklog JSON envelope went away.
Use the /rest/api/2/user endpoint to retrieve the user's username based on its key. This should return something like: