Weekly GDPR API status development update - April 5

Announcements
,
1

Apps are required to migrate to Atlassian AccountID and remove legacy user references (username and user key) by April 29, 2019. 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).

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

  • Email address hidden by default - A new API is available for approved apps to get access to unrestricted access to email address. Read these guidelines for more information about how to request access to the Email API.

Issues with workarounds

The below issues have workarounds and therefore have been de-prioritized from our list of blockers. Please refer to the tickets for more details on the workarounds.

  • Account ID not working in notify resource - This issue was raised in ACJIRA-1746. In order to get accountID in the notify resource youā€™ll need to include the ā€œstrict modeā€ header in your REST call (x-atlassian-force-account-id:true).

  • Jira sidebar fails to render for Project Admin Tab Panel without legacy user context parameters - This issue was raised in ACJIRA-1736. Jira completed their investigation of this issue and discovered that if the order of parameters is changed or any parameters are omitted, then the navigation fails to render. In terms of the upcoming API deprecations it should be possible to include the legacy context parameters to stop the navigation failing to render. Jira will look into improving the handling of parameters for this feature but that may not be done before the planned deprecation of legacy user references.

  • Jira does not recognize issue entity property aliases - This issue was raised in ACJIRA-1723. The guidance from the Jira team at this time is the same as the above (manually convert expressions that cannot be automatically converted by the PD Cleaner).

  • Jira does not have an API to edit workflows -This issue was raised in ACJIRA-1718. The guidance from the Jira team at this time is to update post function data from its configuration form.

  • Problem exporting / importing user data in Jira - Exporter Cloud - This issue was raised in ACJIRA-1751. Export as CSV currently produces user names, and importing of CSV data currently understands user names and commits to not breaking the import/export functionality until resolving issues raised in that ticket.

Items In Progress

  • 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. The Jira team is updating the PD cleaner to return an error instead of converting the results to ā€œunknownā€. The fix for this is rolling out now and the ACJIRA ticket will be updated once complete.

  • JQL transformed to remove legacy user references and replaced with accountID are un-readable - Weā€™ve built a JQL Editor Dialog component that will display the userā€™s current name in JQL rather than the accountID. See ACJIRA-1710. A new issue tracking the development of JQL rendered in advance mode was raised. We do not have an estimate fix date for this. See ACJIRA-1768

  • Jira incoming webhooks missing accountId - This work is still in progress. We do not have a new fix date. See ACJIRA-1692.

  • 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.

  • Jira comment authors missing accountType information - We do not have an estimated fix date yet. See ACJIRA-1765.

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 .

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.

3 Likes
2

Good to see that the email API has been deployed. Iā€™ve read the docs and fetching a single userā€™s email address works fine, but I am not receiving results when fetching bulk user emails. I tried to pass the query param accountId to the /rest/api/2/user/email/bulk endpoint in three different ways without success:

  • accountId=1&accountId=2
  • accountId=1&accountId=2
  • accountId[0]=1&accountId[1]=2

(of course instead of 1 and 2 I am using existing accountIds in my instance)

3

Hi,

Do you have current information about apps (ready or blocked)?

Weekly GDPR API status development update - March 29
Today, we have 199 apps that have signaled that they are ready for the deprecation, 79 that have signaled they are blocked, and ~400 that have not indicated their status.

Thanks.

4

Thanks. The correct format is the first option you have used.

  • accountId=1&accountId=2

We have determined the problem and a fix is in the production pipeline.

2 Likes
5

I can confirm that the bulk email API now works as expected. :smile:

1 Like
6

While rewriting our user sync functionality Iā€™ve stumbled against another issue with the email API. When weā€™re receiving user_created webhooks with an accountId it takes a while before the /rest/api/2/user/email endpoint returns an email. It takes about 2 seconds before that endpoint returns an email. Currently, as a workaround, Iā€™m trying to fetch an e-mail every second.

7

@akassab does the gdpr:true flag also work for BitBucket connect? I donā€™t see any mention about it in the BitBucket Connect documentation.

8

@remie - No, it wonā€™t. The apiMigrations gdpr:true flag is only available in Atlassian Connect (for Jira and Confluence).

9

Hi, I could not reproduce any significant delay in my testing.

Itā€™s probably worth opening a ticket at Jira Service Management and we can explore the issue in more detail,.

Iā€™d interested in how you are creating the users, what the endpoint is returning and when, etc.

Thanks