Weekly GDPR API status development update - March 21

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

Today, we have 149 apps that have signaled that they are ready for the deprecation, 85 that have signaled they are blocked, and ~480 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

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

  • Get current user’s locale ( ACJS-1073) - AP.user.getLocale() is now available. For performance concerns please consider using cacheable app iframes.

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 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 guidance from the Jira team at this time is to manually convert expressions that cannot be automatically converted by the PD Cleaner.

  • 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 user picker REST API missing account type - The Jira team expects this to be released by March 27, 2019. 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. 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. See ACJIRA-1692.

  • 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 was expected to ship this week but has been delayed. We do not have a new estimated ship date yet. 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). The new estimated date for this is March 29, 2019 See ACJIRA-1726

  • 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

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.

1 Like
2

Thanks for the update @akassab. Current user’s locale and timezone is important for our app (Atlas CRM) for internationalization. I’ve read that loc and tz will no longer be included as context parameters and will only be available through JavaScript APIs. This solution will not work for our app, because we do not have access to the JavaScript APIs due to the way we’ve built our app. Will there be an alternative way to also retrieve the current user’s locale and timezone? Perhaps in the JWT claims?

3

Hi @akassab,

thanks for the summary!

Concerning our remaining ‘blocked’ apps (4 Confluence and 1 Jira):

  • For both the Confluence and Jira apps we will need to do some final testing with the profile privacy controls. We’ve raised DEVHELP-2454 and DEVHELP-2401 for this a couple of days ago but have not heard back since then.
  • What is the rollout status of the recently resolved ACJS-1073 (AP.user.getLocale)? I’ve seen it on my developer instance but can we assume this has been rolled out to all instances by now? FYI @dmorrow
4

Hi @akassab, as always thanks for the update!

You are writing about the status of the issues ACJIRA-1686 and ACJIRA-1722 regarding account type. What about the status for ACJIRA-1674 ? I can’t see the account type in the webhooks so far. In the previous update on 7th of March you have mentioned it will be shipped at the end of that week. This is almost two weeks ago now. Any updates here?

As @jens noted, we’re also waiting to be approved for testing the profile visibility controls.

5

Hi @akassab - please can you provide an update on the Confluence Cloud PD Cleaner REST API? I can’t see any in the published docs about it. @sluthra said it was nearly complete.

6

Hi, we are in the process of updating our app, but have not yet opt’ed in with the gdpr flag.

I can see that we have started receiving webhooks with accountId instead of userKey. I thought we had until 29 April 2019 (Are you ready for the GDPR API deprecation? - Atlassian Developer Blog) before the change took place, unless we opted’in


Did I misunderstand something?

Do I need to set the gdpr flag to false until we are ready?

1 Like
7

Hi,
we observe the same behavior

8

Hi @akassab,

Regarding the workarounds for ACJIRA-1725, ACJIRA-1723 and ACJIRA-1718 has the impact on the end user been considered? With out all affected vendors showing messages to all affected users how will a user know they need to take action or their experience of Jira will break?

I believe that ACJIRA-1725 affects end users regardless of whether they use apps or not.

In short I do not believe that any of the issues I mention above have workarounds that are acceptable.

Thanks
Jon

1 Like
9

Hi @f.demir - Theres a long discussion on the ACJS ticket but in short no. loc and tz will only be available through the JavaScript APIs and not through context parameters. If you are concerned about performance we’d recommend implementing cacheable iframes.

10

@jens, the AP.user.getLocale() method is available in all tenants.

1 Like
11

@niels Yes, you need to set the gdpr flag to false until you’re ready. It’s just to signal to Atlassian that you’re working on it, Atlassian’s API will not change by setting it to false. You still have until 29 April 2019 before setting it to true.

Quote from their blog:

We are actively monitoring this flag for published apps. Updating this flag to false tells us that you are actively working on migrating your app and that you are not yet ready for deprecation. Setting this flag to false will have no effect on the APIs your app uses.

12

Also, for which webhooks are you receiving accountId instead of userKey? That shouldn’t happen if you haven’t opted in to the new APIs.

13

Okay, but why am I then already getting webhooks with accountId instead of userKey?

14

I am getting worklog_created webhooks where the author only has an accountId.

And to make it more interresting, my worklog_updated hooks still have the key on author.

This must be a bug right?

15

That does sound like a bug.

16

Thank you for your reply @akassab. I am not concerned about performance. Our app works by authenticating our customers with atlassian id and redirecting them to our app.
So, we’re not in iframes and we do not have access to the JavaScript APIs. Exposing timezone and locale only through the JavaScript API will therefore not work for us. Adding locale and timezone as JWT claims will work for us.

17

@akassab Can you confirm that this is a bug, and do you know if it is something that will be fixed?

In short, I am receiving worklog_created webhooks from my app where ‘author’ only has an ‘accountId’, even though I have set the gdprFlag to false.

18

This endpoint is inconsistent — it does not always return user data (for some users within the same Jira instance it works properly, while for others it responds with 4xx).

19

@jbevan - the documentation for CQL Cleaner for Confluence has just been released.

20

Hi @akassab,

Thank you for the update. We’ve just completed the 4th of our current 4 commercial cloud apps GDPR updates. It has been a lot of work for us and I’m sure for everyone here.

Because of a known MarketPlace bug our new and glorious GDPR enabled descriptor is not being picked up. We have set aside this week to closely monitor the new release. Atlassian removing our conflicting defunct rejected Cloud app with the same plugin key should only take 5 minutes:
https://ecosystem.atlassian.net/servicedesk/customer/portal/9/AMKTHELP-15911

In the interest of supporting the GDPR battle cry this is a request to help us close out our GDPR victory lap.

Cheers,
Brendan

2 Likes