Uploaded image for project: 'Jira Cloud'
  1. Jira Cloud
  2. JRACLOUD-36642

After renaming users in JIRA, worklogs do not expand author correctly in REST API

    XMLWordPrintable

Details

    Description

      NOTE: This bug report is for JIRA Cloud. Using JIRA Server? See the corresponding bug report.

      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:

      http(s)://jiraEndpointUrl/rest/api/2/issue/{issueKey}
      
      http(s)://jiraEndpointUrl/rest/api/2/issue/{issueKey}/worklog
      
      http(s)://jiraEndpointUrl/rest/api/2/search?jql=issueKey={issueKey}&fields=key,worklog,subtasks
      

      expanded worklog authors as follows:

      {"name":"username in format A","active":false}
      

      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

      http(s)://jiraEndpointUrl/rest/api/2/issue/{issueKey}
      

      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.

      Workaround

      Use the /rest/api/2/user endpoint to retrieve the user's username based on its key. This should return something like:

      {
          "active": true,
          "avatarUrls": {
              "16x16": "http://localhost:8080/jira/secure/useravatar?size=xsmall&avatarId=10122",
              "24x24": "http://localhost:8080/jira/secure/useravatar?size=small&avatarId=10122",
              "32x32": "http://localhost:8080/jira/secure/useravatar?size=medium&avatarId=10122",
              "48x48": "http://localhost:8080/jira/secure/useravatar?avatarId=10122"
          },
          "displayName": "Matheus Fernandes",
          "emailAddress": "mfernandes@atlassian.com",
          "expand": "groups",
          "groups": {
              "items": [],
              "size": 7
          },
          "key": "matheus",
          "locale": "en_US",
          "name": "mfernandes",
          "self": "http://localhost:8080/jira/rest/api/2/user?username=matheus",
          "timeZone": "Brazil/East"
      }
      

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              8e75572e67ae Sempla IT
              Votes:
              31 Vote for this issue
              Watchers:
              32 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: