Weekly GDPR API status development update - April 26

Apologies for missing last week’s update. As mentioned in our earlier updates the deadline for migrating to accountID is next week.

I wanted to provide a bit more detail on our roll out plan this week to help prepare you for any customer inquiries that come in as a result of the change.

Roll out Plan (as of 2019-04-26T07:00:00Z)

Bitbucket APIs

Bitbucket will roll out the new APIs to a small percentage of customer instances starting on 2019-04-29T16:00:00Z. We intend to monitor customer support queues closely for ~2 weeks to identify any issues that need to be addressed before significantly increasing the percentage on 2019-05-13T16:00:00Z, which we will then again monitor for issues before rolling out to 100% of customer instances. Target date for 100% rollout is currently 2019-05-20T16:00:00Z.

Jira APIs

Over the past few weeks we’ve strongly encouraged signaling via your connect app descriptor on your ‘readiness’ for the change. Setting the apiMigrations flag to gdpr:true meant that you’ve tested the new APIs using the descriptor and header/query parameters in your REST calls and that you’ve addressed any issues that resulted from your own testing. gdpr:false meant that you were still working on the changes and not ready for the migration.

Jira will begin rolling out the new Jira & Atlassian Connect APIs to apps that have signaled gdpr:true on 2019-04-30T23:00:00Z. We will monitor customer support queues for issues while gradually rolling out the APIs to apps over the course of the week. By 2019-05-09T23:00:00Z we expect to have 100% of apps that have signaled they’re ready (gdpr:true) using the new APIs.

Jira apps that are currently signaling gdpr:false will be whitelisted until they update the app descriptor to gdpr:true. The whitelist will be preserved until 2019-05-16T23:00:00Z after which apps that are still signaling gdpr:false will be forced to use the new APIs. If you are currently signaling gdpr:false and would like to know specifically when your app will be removed from the whitelist so that you can prepare your support teams, please raise a DEVHELP ticket. Target date for 100% rollout is currently 2019-05-19T23:00:00Z.

Confluence APIs

Confluence does not have a mechanism to gradually rollout these changes. To reduce impact on our support teams we are planning to offset the rollouts for Jira and Confluence. Confluence is currently confirming their roll out date but tentatively targeting 100% roll out on 2019-05-29T16:00:00Z.

Roll out status updates

I will use these weekly update posts to provide ongoing status updates for the roll out and to inform you if anything changes.

Communicating to our customers

Many of you have commented that you haven’t seen much in the way of communications to our customers for these changes yet. We have been finalizing the customer facing messaging for the roll out of Profile Visibility Controls which is tentatively targeted for roll out at the end of May.

The API deprecation roll out which was described in the “Roll out Plan” section above is separate set of changes to the launch of profile visibility controls. We may have caused some confusion including the testing for profile visibility controls in our weekly status update posts. To clarify, the roll out of new APIs is largely the removal of username and user keys from our REST APIs (the changes described in the API Migration guides). The user object returned with accountID will not change, meaning all fields will continue to be passed.

For the API deprecation, we are preparing our cloud support teams with the following messaging:

Customers with user installed apps may experience error messages or reduced functionality.
Error messages may occur if legacy user references (e.g. usernames or user keys) are still being used by the app because our cloud REST APIs no longer accept or return these references.
In some cases, historical configurations like post functions or scripts may have stored a legacy user reference (username or user key) which could not be updated to accountID during the migration window (October - April 2019). In those cases, a workaround may exist to re-save the configuration to overwrite the legacy user reference with accountID. It is best to work with the app vendor directly to identify any workarounds to complete migration. Additionally, some apps may no longer be able to provide localization functionality or present the same context as the host application because timezone and locale were removed from context parameters. Context parameters are additional information sent to apps via URL.

Similar messaging will be made available via our public knowledge base and in our customer community.

Additionally, our support team will continue to direct questions we receive about apps directly to the app vendor. Typically this is done by providing a link to the app listing in Atlassian Marketplace with the support tab highlighted. We recommend updating your app listing to provide a link to your own support documentation on this page (especially any documentation containing guides for completing the migration). If you’d like to share your documentation with us so that the support team can share on your behalf please raise a DEVHELP ticket.

Thank you

As always, thank you for working with us through these changes. Its been a large amount of work to complete in a short timeframe and we appreciate you helping us deliver a more trusted experience for customers.


Thanks for the details of roll out plan.
In Japan, we have long national holidays (Apr 27 to 6 May).
I hope the success of roll out! :slight_smile:

1 Like

Thanks for the update!

Out of curiosity, what happens to apps that have not implemented the gdpr flag at all (neither true/false)? Are they forced to switch like the gdpr: false apps? Or are they going to be removed from the Marketplace entirely?

Could you fix this issue, please - [ACJIRA-1596] - Ecosystem Jira, so we can migrate to Jira version 3 API (though, it seems the GDPR changes and the Jira v3 API roll out date are not in sync - API v3 roll-out date? - #2 by yvesriel)

According to our tests we are forced to use v3 API to assign issues to users using accountId - Creating Jira issue with custom assignee in Jira cloud fails with account not found. But because of the open bug mentioned we cannot use it with custom fields / description field

Thank you for the update!

But it is not clear to me when the Jira Cloud REST API will stop accepting and returning usernames/keys, I understand that for Cloud apps it will be based on the gdpr flag, but if there is no app, just some calls being made to Jira Cloud REST API, when this will be rolled out?

@jhuertas- both inbound and outbound APIs will be changed when your app is opted in to the new behaviors. For Jira this starts today and progressively rolls out to apps thru 2019-05-20T00:00:00Z

Thank you for the prompt response, but I am not asking about Atlassian Connect Apps, lets say I have a simple python code that makes a request to my JIRA Cloud instance via its REST API, but this python code is not an app, I mean there is no atlassian-connect.json descriptor at all.

@jhuertas - thanks for clarifying. Apps that make requests directly to the REST API will see the new API behaviors as of 2019-04-30T07:00:00Z.

Both of our cloud apps are marked as gdpr:false, and they stopped working recently. How can we fix it? Customers are worried.

Hello - we are seeing behavior that varies across customers. We get inbound webhooks and some customers are sending account ID values when mentioning on comments in the JSON and some are the old [~nick] format. Is this supposed to be consistent at this time?

We started replacing [~nick] with accountid:… so acting differently across cloud teams is creating issues.

1 Like

@dmitry.astapkovich - We have not rolled out any of the new APIs yet. Jira was delayed in finalizing the whitelist for apps that have indicated gdpr:false. We will likely start rolling out next week - I will provide an update in this week’s update on date and time.

@akassab, both of the add-ons we develop have disappeared from side menu, issue view,
issue navigator and boards. If users tried to open the reports with saved
link, they received 500 error.

There was no changes from our side, it just started to happen. After
investigation we realized that all permission code we had is no longer
valid because of user id API change. So we had to remove all permission
validation, updated the add-ons and they started working again.

As for the moment we are planning to migrate to gdpr complacence this
weekend. Hopefully it will work out. But to be honest this case is
extremely frustrating for us as vendors.