We’re making changes to our cloud products to provide users with more control over their profile information - both in response to recent changes to data privacy legislation (i.e. GDPR) and as part of a broader effort to improve customer trust.
These changes require apps to migrate their app and data stores to a new global identifier - the Atlassian AccountID and remove legacy user references (username and user key).
Recap on timeline
We announced the deprecation of legacy user references in October 2018. Per our standard deprecation policy, apps have 6 months to complete the migration to accountID. On 29 March 2019 Jira, Confluence, Bitbucket and Connect Cloud REST APIs currently containing username and user key will only return accountID.
In addition to the migration, you will need to prepare for profile visibility controls which we intend to launch in mid April 2019 . These profile visibility controls will create variability in the user object based upon preferences set by the user. This means that fields that are currently available (i.e. email address) will no longer return or return null.
We’ve recognized that there are a number of issues you’ve identified affecting your ability to migrate and prepare for profile visibility controls. In the spirit of Atlassian’s Open Company, No BS value, we’ll go over each of the open items that we are currently working on and provide estimates of completion. Please note that these dates may change. We will provide these updates weekly.
Recently closed issues
- Jira change logs containing username missing accountID - The Jira API migration guide describes an opt in mechanism which can be used to force accountIDs to be returned in Jira change logs. To convert Jira change logs from username to accountID use the x-atlassian-force-account-id: true header in your REST call to retrieve change logs.
- Conversion of stored JQL containing legacy user references to accountID - The Jira API migration guide describes a ‘PD Cleaner’ operation which can be used to convert stored JQL containing legacy user references to accountID.
Items in progress
- Jira and Confluence webhooks bodies that contain username and/or user key missing accountID - We are working to update webhooks to contain both legacy user references, accountID and account type. We expect this work to be complete for both Jira and Confluence in approximately 2 weeks time.
- Issues with updating data stored in product - We’re aware that there are certain challenges with migrating data stored in the host product. For example, if the app requires a user action to update which may not have occurred during the deprecation period or if the app lost access to the storage location either by changes to permissions or uninstall. We are planning to facilitate migration of those legacy user references to accountID by providing a new API endpoint unaffected by the 29 March 2019 deprecation of username / user key which will continue to allow you to lookup old user references and convert to accountID. Jira has already released this endpoint (see: /rest/api/3/bulk/migration) and Confluence is planning to release this endpoint before end of February 2019. You should expect these APIs to be temporary, as it is important for us to remove use of username and user key.
- Conversion of stored CQL containing legacy user references to accountID - The Confluence team is developing a similar solution to the one that’s currently available for Jira. We don’t yet have a confirmed date for completion but will provide an update in a week’s time.
- Testing Profile Visibility Controls - We intend to provide you with time to test profile visibility controls before we launch. We will provide more information on how to test in 2 weeks time.
- Email address hidden from public by default - Email address will be hidden from public by default which means that the email address will no longer be provided to you through our product APIs for the majority of users. Users will need to manually adjust their profile visibility control settings in order to provide access to email. We recognize that for some of you this restricts core functionality. We intend to enable access to email for approved use cases only. We will provide more detail in 2 weeks time.
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. If you are no longer blocked please opt in to the new APIs using the opt in mechanisms described in the migration guides to signal to us that you’re ready.