Jira Cloud REST API privacy updates and migration guide

announcement
deprecation
jira-cloud
gdpr

#83

@nirav.shah I don’t know this will be helpful in your case or not. But we are planning migration like this.

We are using GET /rest/api/3/user/search Rest API. If you pass % as query parameter then it will return all the users. Then we can find relevant account ID for specific user key.

Thank You.


#84

Ah that seems to be a documentation bug. It works with https://site.atlassian.net/rest/api/3/user/bulk?username=user1&username=user2&username=user3


#85

If the addon user was removed, all permissions for that addon would be revoked. Yes this would be a problem, but it would break all permissions for that addon, not just bulk user lookup. That is, the addon would not even have read permissions any more.

I’m not saying that this doesn’t happen, but the alternative is to make an API where customers cannot possibly revoke permissions.

Perhaps a way around this is to check if the addon user can do the things it needs, and warn the customer if something’s wrong. “Hey it looks like this application is missing some permissions that it needs in order to work correctly. Please contact your site admin to get that fixed.”

Note that removing and re-adding an addon (or in fact, installing any addon) repairs the permissions.


#86

Hi @bkelley - Not necessarily that the AddOn stops working. From within the App, the calls to user are always made on behalf of users. So likely of App not working is very less. Now, going back and asking every customer to removing and re-adding the add-on is not the simplest one ( agreed if there are couple, but if there are hundreds - than its not feasible ). We will need something from Atlassian to help us out on that


#87

Hi @dhara.ghodasara - Thats what we are using but that only works if the addon user has Global Permission for Browse User and Group else it won’t work.


#88

@akassab - Can you please have someone check this and let us know what has to be done. We cannot reach out to customers asking them to add add_on user to the Global Permission for migration. If it was few we could have done that. We are seeing a lot of customers across both our cloud products who have removed AddOn Users from Global Permission (Browse Users and group)


#89

Hi @akassab,
where are we supposed to report issues we encounter during our GDPR migration?

We have completed the first part of our migration and are encountering bugs during testing. For example:

  • the AP.getUser method that was introduced for static web panel modules doesn’t return the accountId (nor the userKey once we activate the gdpr API migration in our descriptor), and the AP.context.getContext API never returned any user info (no user field in the response, only jira) for static web panel modules, regardless of the gdpr option (unlike what’s documented in https://developer.atlassian.com/cloud/jira/platform/jsapi/context/). Bottom line is, we can’t get the current user at all.
  • the /rest/api/2/issue PUT endpoint doesn’t accept setting a user-type field such as the Assignee with either accountId or userAccountId (tried both), even with the gdpr API migration and the x-atlassian-force-account-id: true header

And this is just the beginning of our tests.

Where should we report all this? Raise a developer support request?

Thanks,
David


#90

Hi @bkelley ,

During the migration of user privacy settings, we have faced that few Jira APIs are not working as expected. Regards of this, we have created ACJIRA-1639. Currently we are stuck for further development from our end. Once this ticket will be rolled out, we can do further development.

Would you tell us ETA of this ticket as it will really help us to plan further.

Thank you.


#91

@nmansilla We are using this REST API with % as a query, as per the changes rolled out,

https://yourinstance.atlassian.net/rest/api/2/user/search?startAt=0&maxResults=1000&query=%

I would like to know whether it’s a legit way to fetch all users of the Atlassian instance.

Also, we are looking for a POST API which accepts list of account Ids and return users matching those account Ids. I think such API would be really helpful, otherwise either we can fetch all users and cache them (not sure caching user detail would comply with GDPR or not) or we call Atlassian for individual account Id which I don’t think a good option in terms of performance.

Looking forward to your response. :slight_smile:

Thanks.


#92

Hi @david2, the bug you’ve mentioned with PUT /rest/api/2/issue is already tracked here https://ecosystem.atlassian.net/browse/ACJIRA-1613 and here https://jira.atlassian.com/browse/JRACLOUD-71201.


#93

Hello,

Somewhere the Jira Cloud matches some latest version of Jira Server.
Is the deprecation going to happen for just the Jira Cloud version or some Jira Server version is also going to have these API changes also?

Thanks in advance.

Regards,
Nimish


#94

@akassab / @nmansilla / @bkelley - Can someone please provide any insight ?

Anyone facing similar issue related to Global Permission removed and hence cannot migrate the customers?


#95

@nmansilla can you expand on the statement in the original Migration Guide that says:

By 29 March 2019, we will remove personal data from the API that is used to identify users, such as username and userKey

I know that most/all of the APIs now support accountId where necessary and we can use a combination of descriptor change and HTTP header to opt-in to some GDPR changes ahead of that deadline, but:

  1. when are the existing APIs just going to stop working with username/userkey (is it midnight on the 29th, and if so which timezone)?
  2. how are they going to stop working (will they return an error code)?
  3. when will existing JQL queries be migrated by Atlassian to no longer store userkeys/usernames?

#96

@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?


#97

@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?


#98

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