Weekly GDPR API status development update - March 14

Apps are required to migrate to Atlassian AccountID and remove legacy user references (username and user key) by April 29, 2019 (Europe: Paris), April 29, 2019 (America: Los Angeles). For more background on why - please see our first post .

Understanding migration status

We are tracking use of the apiMigrations flag in the Connect App descriptor as a way to understand developer readiness to deprecate username and user key from our REST APIs. This flag serves as both a mechanism to test the new API behaviors (when set to gdpr:true) and a communication tool to signal when you are blocked (when set to gdpr:false).

Today, we have 80 apps that have signaled that they are ready for the deprecation, 44 that have signaled they are blocked, and ~600 that have not indicated their status.

In order for us to understand where you are with migration to accountID and use that information to effectively communicate with our product teams we need you to signal your status using the “opt In mechanism”.

Learn more about how to properly use this flag.

Additional note on opt’ing into the new API behaviors

The flag described above controls Atlassian Connect behaviors. When opt’d in gdpr:true only the APIs related to Atlassian Connect will change this includes: Inbound Auth, Outbound Auth, App iFrames, App Lifecycle, Webhooks, and JavaScript API. To change the behaviors of Jira and Confluence REST APIs you will need to pass additional header/query parameters on every REST call. The header for Jira APIs is x-atlassian-force-account-id’:true. This header is also required to transform change logs from username to accountID. The query parameter for Confluence is privacyMode=true.

Note: Jira webhooks (query parameters and webhook payloads) still contain user_id and user_key even when opt’d into the new API behaviors via the connect descriptor. We are planning to address query parameters but not webhook payloads. Please comment below if continuing to receive these soon to be deprecated fields in webhooks during the opt in period creates a critical blocking issue for you.

Recently closed issues

  • AccountID in JQL statusby clause does not work - Jira has rolled out a fix this week. See ACJIRA-1625, and ACJIRA-1704.

  • Confluence documentation for new REST endpoint for migrations - Jira and Confluence have new migration APIs that are unaffected by the 29 April 2019 deprecation. (See here for Jira: /rest/api/3/migration ) The endpoint for Confluence is documented here.

Items in Progress

  • Jira user picker REST API missing account type - The Jira team expects this to be released by March 20, 2019 (Europe: Paris), March 20, 2019 (America: Los Angeles). See ACJIRA-1686.

  • Jira post function /triggered calls missing accountID and account type - This issue was split from the above. The Jira team has is preparing to work on this issue. The estimated fix date is March 27, 2019 (Europe: Paris), March 27, 2019 (America: Los Angeles). See ACJIRA-1722.

  • Jira incoming webhooks missing accountId - Jira is planning to add a separate event that will use accountIds. The estimated fix date for this issue is March 27, 2019 (Europe: Paris), March 27, 2019 (America: Los Angeles). See ACJIRA-1692.

  • Jira does not recognize issue entity property aliases - The Jira team is still working on this issue. It was meant to be complete this week but still has not shipped. We do not have an updated estimate for this work yet. See ACJIRA-1723.

  • Jira does not have an API to edit workflows - The Jira team has temporarily paused work on this issue. We do not have an estimate for when the work will resume nor an estimated fix date at this time. See ACJIRA-1718.

  • JQL transformed to remove legacy user references and replaced with accountID are un-readable - We’re building a JQL Editor Dialog component that will display the user’s current name in JQL rather than the accountID. This work is in progress and we expect this to ship March 19, 2019 (Europe: Paris), March 18, 2019 (America: Los Angeles). See ACJIRA-1710.

  • Email address hidden by default - The Email API is being worked on now. We are delayed a bit (we expected the work to be complete this week). We do not yet have a new estimate for when this work will be complete. See ACJIRA-1726

  • Jira PD Cleaner converting user strings that are not exact usernames to ‘unknown’ - This issue was raised in ACJIRA-1712 but now is being tracked in ACJIRA-1725. We still do not have estimates for how/when this will be fixed.

  • Account ID not working in notify resource - We are looking to close this next week when the Jira API Migration guide is updated but in order to use the notify resource with account ID you’ll need to include the strict mode header in your REST call (x-atlassian-force-account-id:true). The work is being tracked on ACJIRA-1746.

  • Get current user’s locale - We intent to provide a new JS API similar to AP.user.getTimeeZone() to provide the current users locale. For similar reasons to the decisions around timezone we will only provide this via a JavaScript API. See ACJS-1073

  • Jira sidebar fails to render for Project Admin Tab Panel without legacy user context parameters - Jira is currently investigating this issue. We do not have an estimated fix date yet. See ACJIRA-1736.

  • Missing avatarURL with opt in header (x-atlassian-force-account-id:true) - Avatars should be present with the opt in. Jira is currently investigating this issue. We do not have an estimated fix date yet. See ACJIRA-1732.

  • Testing Profile Visibility Controls - We intended to be ready to set up developer instances for testing profile visibility controls this week, however we are delayed a bit. We expect to be able to enable testing in the next week or so. In the meantime please read the guide.

Testing Profile Visibility Controls

If you are ready to start testing profile visibility controls, please raise a ticket in our Developer Support Help Desk here . We are not quite ready to set up developer environments but this guide will describe how testing will work and what you can expect once privacy controls are turned on.

Thank you

We realize this is a large amount of work to complete in a short timeframe. We appreciate you working with us through this process to deliver a more trusted experience for our customers.

If we’ve missed anything preventing you from completing the migration, please comment below.


Thanks @rwhitbeck - do you have a ticket we can watch for the progress on the CQL PDCleaner? @sluthra said it was in progress…

Hello @akassab and thanks for the update!

We’re in the process of migrating our Confluence app. We’ve previously relied on the body.storage response from /wiki/rest/api/content/{id} which returns the page content in XML format. In there, we look for <ri:user ri:userkey=“8a7f808360575f7501606910dc1600cb” /> tags to identify users when they are mentioned.

These tags are not updated to use Account IDs when calling the REST API with the privacyMode flag and updating the apiMigrations gdpr flag in the descriptor. Do you have any plans to update the body.storage XML or is there another way to get mentions in a Confluence page with Account IDs?

Edit: The body.editor2 format seems to return tags including an Atlassian Account ID. Should we use those instead? On https://developer.atlassian.com/cloud/confluence/rest/#api-content-post it is mentioned that “Note, editor2 format is used by Atlassian only.” and I want to make sure we don’t have to do another migration anytime soon.

1 Like

Hi @jbevan CQL PDCleaner is ready. We will hopefully have documentation for it updated in a week


Trying to migrate existing entries in the App database from using user key to accountId according to this post (Tip #4): https://developer.atlassian.com/blog/2019/01/speed-up-your-jira-confluence-migrations-accountid/

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?

Because of the way we’ve built Atlas CRM we are not able to use front end APIs to fetch data. Will there be an alternative way to also retrieve a user’s locale and timezone? Perhaps in the JWT claims?

It seems that using [~accountId] format for Jira markup in comments is not working yet. Any ideas when this will be live?

Did you test with [~accountId:557058:fee2c14d-2d17-45ab-af91-a46e792ececd], which is the official way of mentioning a user by accountId?

1 Like

Ah well… I did not! Thanks :slight_smile:

Hi akassab,

Before all, thank you for the regular status updates about Gdpr migration.
Our plugin is “almost” ready, we migrated users in order to use accountId, and today I wanted to put “gdpr”=true flag to our descriptor - and surprise, I saw that the locale param was deprecated :frowning:

Since we are using @RequestParam(“loc”) String loc
in our java rest api, we will need to find another solution since the locale param has been removed.

We could start using js to get this info, so we will need you guys to finish the https://ecosystem.atlassian.net/browse/ACJS-1073

Is there any other way that we could get this info in java ? Our current solution is to use the client browser locale in js.

Thanks for the great job so far