Jira Cloud REST API privacy updates and migration guide

@nmansilla - Current JWT documentation says

User context claim of JWT currently contains user key, user name and user display name. During the deprecation period we are adding account ID here. After the deprecation period the claim will be removed altogether, since the sub claim will contain the account ID.

We are using the force GDPR on our testing and we don’t see the sub claim passing the accountId, we still see the userkey. Can we get that verified?

@nirav.shah We are also facing the same issue. Did you find out any other way except reaching out customers and tell them to give permissions?

@dhara.ghodasara - No, we have not found any other way.

@dhara.ghodasara - [ACJIRA-1664] - Ecosystem Jira (i have this request filed for Atlassian).

Has anyone else found similar issue and were able to have a work around?

Thanks Nirav for update.

Hi David,

Have you seen AP.user.getCurrentUser()? It returns the current user’s account ID.

Regards,
Dugald

@dmorrow yes, thanks, someone pointed it out to me on EAN. I forgot to post the solution back here.
David

1 Like

Hello,

I’m using /rest/api/3/groupuserpicker?query=% , there’s a field named html. Will it exist and contain value after the privacy update?

Hi. Yes the html field will continue to exist. After the privacy update it will no longer contain the username part though. (You can see this now by setting the HTTP header to opt in to REST APIs.)

Hi @bkelley ,
this might be a dumb question and I’m not sure if this has been asked before (although I searched for it).
We developed an add-in for Microsoft Excel accessing REST APIs that have no username/userkey-relation (e.g. boards, issue, issuetypes).
Are these REST APIs also affected or is this change only restricted to usernames/userkeys due to privacy issues?
Thanks for any support/help and kind regards
Eric

@xtractor - you can view the deprecation notice here, which contains an overview of resources/methods being affected. That being said, it would be a good idea to use the opt-in header on your API requests to get an idea of how the payloads are changing.

2 Likes

What @nmansilla said. (Thanks!)

Hey @nmansilla
We are trying to migrate existing entries in the App database from using user key to using accountId via /rest/api/3/user/bulk/migration?key=... according to this post (Tip #4): How to speed up your Jira and Confluence app migrations to accountID - Atlassian Developer Blog

The problem is that some hosts do not return any information for a given user, while others do.
Is it a bug?

Where should I create a ticket with additional information?

What will the user experience be of the advances issue search in Jira?

Are they going to see the account ids instead of user names in the final JQL?

What about entity properties that contain the account ids? Will they be populated with something user friendly in the Jira search UI?

1 Like

Hi @daniel2 - We’re working on a JQL component that will display a friendly name (either the full name or nickname - depending on user preferences) in place of accountID. Check out ACJIRA-1710 to find out how to use the early access version of this API.

Hey, and is the same component going to be used in the Jira itself (advanced search)?

Looks like /rest/api/3/jql/pdcleaner endpoint doesn’t replace the user keys that are assigned to entity property JQL aliases. Is this going to be fixed before the deadline?

1 Like

pdcleaner now recognizes custom entity property aliases if their type is set to USER: [ACJIRA-1723] - Ecosystem Jira

@akassab ACJIRA-1710 is now closed but there is no way to make it return the JQLs with accountIds. Is the related ACJIRA-1768 ticket going to fix it and is it going to be delivered on time?

Issue notification API is not working since last Friday. Jira Service Management

It could have been easier in the event that they simply stuck the accountId in the username field. This might have drastically decreased the amount of article of labor required in converting existing information, but still wouldn’t have affected my factors above