Jira Cloud REST API privacy updates and migration guide

rwhitbeck · October 15, 2018, 7:29pm

I can jump in on this question, as these changes are only relevant for our Cloud products and not Server you’ll have total control of your app to update all of your customers at once as your apps will automatically update when you update it.

paul · October 15, 2018, 7:36pm

Hi @rwhitbeck, I have some users that are still on older versions of my plugin (I think this was where the permissions changed) and they aren’t updated (I assume they have to accept the new permissions). What happens if I need to change the user id or key passed into screens through the atlassian-connect.json

Thanks
Paul

akassab · October 15, 2018, 7:37pm

@paul - are these users on private versions of your cloud apps?

paul · October 15, 2018, 7:38pm

@akassab they aren’t, I am the only one that uses the private versions

Thanks
Paul

pweinberger · October 16, 2018, 3:14am

Hi @ElementML,

It should be fairly straight forward. Just update the username in question to accountId. Like this:

project = “yourproject” and assignee=pweinberger ORDER BY priority DESC

to

project = “yourproject” and assignee=8ad65abc53def45456dead3 ORDER BY priority DESC

Could you please post an example jql and I can take a look at it?

jmort · October 16, 2018, 6:48am

Is there an API we can submit legacy JQL to and have it converted into the accountId version? We have many stored JQL strings that need updating. Unless Atlassian provide something, every vendor is going to have to implement the same thing.

Also we have the workflow post function problem. Data stored in postfunctions contains userKeys which need migrating to accountId, but we can’t do it.

paul · October 16, 2018, 6:52am

@jmort, I have the postfunction problem as well, haven’t managed to get an answer on what to do yet though

ElementML · October 16, 2018, 1:48pm

Hi @pweinberger,

It should be fairly straight forward. Just update the username in question to accountId. Like this:

project = “yourproject” and assignee=pweinberger ORDER BY priority DESC

to

project = “yourproject” and assignee=8ad65abc53def45456dead3 ORDER BY priority DESC

Could you please post an example jql and I can take a look at it?

Thanks for the reply. I do understand how the queries need to change in order to work with the accountId, my question was more along the lines of whether Atlassian would be providing a more automated migration path for actually making the changes in question.

If not, every Marketplace vendor that stores user-supplied JQL is going to have to implement their own solution for parsing the queries, identifying the fields that contain usernames or keys (including custom user picker fields, which are of course different for each Jira tenant), looking up the accountId for each parsed username, validating the new query, etc. This is a significant development effort, and it seems like a huge waste of resources for the ecosystem if everyone has to roll their own code, particularly given that Atlassian obviously has a method for migrating the queries automatically. What I was really hoping for was an endpoint that we could hit with a valid JQL query and receive a valid, migrated query in the response.

(EDIT: Looks like @jmort beat me to it.)

Cheers,
Mark

ElementML · October 16, 2018, 1:52pm

Hi @rwhitbeck,

I can jump in on this question, as these changes are only relevant for our Cloud products and not Server you’ll have total control of your app to update all of your customers at once as your apps will automatically update when you update it.

This isn’t completely true. See this page from the Marketplace docs for the relevant details on manual upgrades of Atlassian Connect apps. Users can have old versions installed forever if there are changes to required data scopes in the app descriptor.

Cheers,
Mark

pweinberger · October 16, 2018, 10:10pm

Such a service is in our roadmap and we plan to do it as quickly as possible.

pweinberger · October 16, 2018, 10:11pm

Repeating my answer to @jmort here.

Such a service is in our roadmap and we plan to do it as quickly as possible.

ElementML · October 16, 2018, 10:42pm

Thanks @pweinberger, that’s great news – appreciate the clarification.

pweinberger · October 17, 2018, 4:51am

Hi @jbevan

No, you are correct. These controls haven’t been made public yet. I don’t have an exact date for when they will be made public, but we’re working on it.

jbevan · October 17, 2018, 8:46am

Thanks for all the extra info, its much appreciated.

I don’t doubt that Atlassian are working on it, but deprecating things without providing alternatives or the ability to test the relevant changes is particularly frustrating for vendors. I don’t mind how long it takes for the privacy controls and API changes to be released, but I do mind if those changes aren’t completed with enough time for vendors to react to those changes before the deprecation deadline (29th March) that has already been set.

Additionally, we’ve still not had any confirmation or clarification on how we’re supposed to migrate post-function configuration that contain userkeys?

aioreports · October 24, 2018, 6:29am

Hi,
Migration guide specifies that only GET methods for search endpoints are impacted. Is that correct?
Will the POST methods accept username and userkey in JQL queries?

/api/3/search
/api/3/issue/picker

Methods

GET

Request query parameter changes

JQL will not allow username or userKey in queries. Use accountId instead.

aioreports · October 24, 2018, 6:32am

Hi,
As per the connect API migration guide here: https://developer.atlassian.com/cloud/jira/platform/connect-api-migration/, we are testing our add-on with the “apiMigrations”: {
“gdpr”: true
}

The JWT seems to honour this flag, but the Rest APIs are still returning the old responses with username and userkey included. We have also tried setting the visibility to private (Screenshot), but it does not change the API response.

pweinberger · October 25, 2018, 2:12am

The avatarUrls field will not be removed. The migration guide examples are being updated to reflect that. The only change is that the links in the avatarUrls field will be different, but shouldn’t affect any logic for third party apps.

satvik · October 25, 2018, 5:46am

@pweinberger When we opt into the GDPR apiMigration, does this apply only to API calls on the Connect server, or does it also apply to API calls made from the browser?

I’m also not clear on what endpoints are affected by opting into to the migration, and whether it applies to v2 API responses?

jbevan · October 25, 2018, 9:16am

As far as I understand things, both v3 and v2 of the REST APIs are affected by GDPR changes, regardless of how those APIs are accessed (via AP in the browser/using curl/from a connect app server etc).

The primary change between v2 and v3 of the REST API is that v3 supports the new Atlassian Document Format. Please anyone correct me if I’ve misunderstood.

morten.stensgaard · October 25, 2018, 10:47am

These GDPR privacy changes, forces us to do our own mapping table of users, when reading project permissions/roles between platforms on the REST API.

Today I use email-prefix(before@) -> username lookup, hence they map 1:1. Easy Peasy! Works without ANY manual intervention!

How can we now do this after April 1st? - We will be forced to maintain a mapping of the unique accountID-> Internal domain account from admin perspective.

Any way of extracting a full list of users/accountIDs on the API or extract per user for usage towards other platforms/integrations.

Currently our integration/functionality is bound to broken by March 29st unless there is a fully automatic alternative to mapping tables.

And sorry to say…Atlassian’s Access AD integration is still ridiculously expensive! (and probably does not read out the AccountId anyways for usage from a central AD perspective)

/Morten