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:
- Different countries and regions seem to have different perspectives when it comes to the privacy of their personal data in the workplace.
- 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:
- Jira API Migration Guide
- Confluence API Migration Guide
- Bitbucket API Migration Guide
- Connect API Migration Guide
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
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 toDeveloper Support for assistance.