State of Atlassian Ecosystem changes to address privacy

February 13th 2019 Alexandra Kassab in GDPR, Jira, Confluence, Bitbucket, Cloud

Update!

Since this blog post was published the deadline for deprecation has been pushed back to 29 April 2019.

A quick reminder: why privacy is critical for our users

We here at Atlassian believe in working openly because when work is open we unleash the full potential in every team. And with the recent changes to data privacy legislation (i.e. GDPR), we really wanted to understand how privacy affects a team’s ability to be open.

So we conducted research with customers from around the globe and learned two important lessons:

  1. Different countries and regions seem to have different perspectives when it comes to the privacy of their personal data in the workplace.
  2. Despite those differences, users prefer to limit the amount of personal data they share when collaborating at work - specifically when they are sharing knowledge or providing feedback.

This research fundamentally changed our definition of “open”. Open doesn’t mean all access. In order to be open and to work openly, users need to be able to trust that they have control over their personal data. Only then does collaboration become less about the individuals on a team and more about the work that the team is trying to complete together.

Key changes and their status

Providing users with greater control over their profile information requires changes to our platform. We’re introducing a new identity model which centralizes user profile information into a single source of truth - the Atlassian Account.

Atlassian Account uses a single global identifier - the Atlassian ID. The Atlassian ID is an alphanumeric string between 1 and 128 characters long and may contain characters such as dash and colon. It is, by design, opaque and safe to store. Legacy identifiers such as username and user key which have been used in Jira and Confluence are neither global nor opaque, so we’re removing them from our product databases and Cloud REST APIs.

This change requires apps built for Jira, Confluence, and Bitbucket to migrate to AtlassianID as well.

On the migration to accountID

In October 2018, we announced the formal deprecation of usernames and user keys from our Jira, Confluence, Bitbucket, and Connect Cloud REST APIs.

See here for the announcements in our developer documentation:

Per our deprecation policy, we committed to providing a 6 month period of time to complete the migrations and communicated that on March 29, 2019 legacy user references (username and user key) will be removed from those public APIs. To facilitate the migration we updated our APIs to include accountID and added opt-in mechanisms in order to enable testing.

Introducing new profile visibility control settings

Our migration guides also mention changes to user objects which will come as a result of a new feature we’re introducing to users in mid-April 2019, the profile visibility control screen.

The profile visibility control screen will allow users to hide or unhide parts of their profile. Fields that are currently returned in the user object today, like email address, may not show up (or return null), depending on the user’s profile visibility control settings.

Additional requirements to support the right to be forgotten

In addition to the changes we’re making to our APIs, we’ve also added new requirements for apps listed on Atlassian Marketplace and registered on developer.atlassian.com/apps. As of December 2018, apps are required to disclose their data storage practices and add both a privacy policy and customer terms of use agreement. Those that are missing information have been de-listed from Atlassian Marketplace.

Cloud apps storing personal data are now also required to provide regular reports on the list of users that have been stored. We’ve created a new API and service to respond to those reports with information about Atlassian Accounts that have been closed. We expect that when apps receive this information they immediately process data deletion.

A trusted experience is something that we’re building together. One bad customer experience can reflect poorly on our community as a whole so we will be regularly monitoring and enforcing these new requirements. We started with de-listing apps that have not provided sufficient information on Atlassian Marketplace, and we will continue with monitoring the use of personal data and the tools we provide to stay in sync.

Challenges and how we’re addressing them

We’ve heard from you about your challenges with migrating both your app and data stores to accountID as well as, preparing for changes to the user object as a result of the new profile visibility control settings we intend to launch in April.

These include (but are not limited to):

  • APIs (e.g. Jira changelogs) and webhooks missing accountID
  • Issues updating stored data either due to the storage location (i.e. in product) or in saved JQL / CQL
  • Lack of clarity on profile visibility control impact on user experience (e.g. search, differentiating users in a list, eliminating unrestricted access to current user timezone)

We’ve addressed items that have been raised along the way, but there are still a few that remain open.

Here are a few examples:

  • Jira and Confluence webhooks do not contain accountIDs, which means that after the deprecation of legacy user references (username and user key), apps can no longer rely on webhooks to differentiate actions performed by app users (as opposed to actual users).
  • Confluence stores CQL with usernames, which means that after the deprecation those queries will no longer work. Jira had a similar issue with JQL and exposed a new operation (“ PD Cleaner”) to facilitate the translation of JQL with legacy user references to accountID.
  • Apps can write data back to the host product (Jira and/or Confluence), which means that data containing legacy user references may no longer work after the removal of username and user key. Jira has provided a new API endpoint to facilitate the migration of username and user keys to accountID which will be unaffected by the deprecation date. (see: /rest/api/3/bulk/migration)
  • Email address will be hidden by default once profile visibility control settings rollout, which means that apps will no longer have access to a users email address. We realize that apps may provide core functionality that requires an email address.

We are committed to fixing these issues on or before March 1, 2019 which will give you 4 weeks for implementing and testing the changes within your app.

It's crunch time - making the next few weeks count!

We’ve been rather lenient on API deprecations in the past - we can’t be when it comes to privacy. That’s why we are sticking with our original deprecation date March 29, 2019 for the removal of username and user key from our public Cloud REST APIs.

If you are unaffected by these changes or are done with the work, signal to us that you’re ready by opting into the new API behaviors where usernames and user keys are no longer passed. For Connect apps this means adding a flag to your descriptor.

If you are still blocked, we are here to help. We are providing a weekly update on the Developer Community summarizing status of current known issues. You can see all of our updates here. Comment on the Developer Community post to let us know of new issues you’re experiencing or reach out to Developer Support for assistance.