Apologies for missing last week’s update. As mentioned in our earlier updates the deadline for migrating to accountID is next week.
I wanted to provide a bit more detail on our roll out plan this week to help prepare you for any customer inquiries that come in as a result of the change.
Roll out Plan (as of 2019-04-26T07:00:00Z)
Bitbucket APIs
Bitbucket will roll out the new APIs to a small percentage of customer instances starting on 2019-04-29T16:00:00Z. We intend to monitor customer support queues closely for ~2 weeks to identify any issues that need to be addressed before significantly increasing the percentage on 2019-05-13T16:00:00Z, which we will then again monitor for issues before rolling out to 100% of customer instances. Target date for 100% rollout is currently 2019-05-20T16:00:00Z.
Jira APIs
Over the past few weeks we’ve strongly encouraged signaling via your connect app descriptor on your ‘readiness’ for the change. Setting the apiMigrations flag to gdpr:true meant that you’ve tested the new APIs using the descriptor and header/query parameters in your REST calls and that you’ve addressed any issues that resulted from your own testing. gdpr:false meant that you were still working on the changes and not ready for the migration.
Jira will begin rolling out the new Jira & Atlassian Connect APIs to apps that have signaled gdpr:true on 2019-04-30T23:00:00Z. We will monitor customer support queues for issues while gradually rolling out the APIs to apps over the course of the week. By 2019-05-09T23:00:00Z we expect to have 100% of apps that have signaled they’re ready (gdpr:true) using the new APIs.
Jira apps that are currently signaling gdpr:false will be whitelisted until they update the app descriptor to gdpr:true. The whitelist will be preserved until 2019-05-16T23:00:00Z after which apps that are still signaling gdpr:false will be forced to use the new APIs. If you are currently signaling gdpr:false and would like to know specifically when your app will be removed from the whitelist so that you can prepare your support teams, please raise a DEVHELP ticket. Target date for 100% rollout is currently 2019-05-19T23:00:00Z.
Confluence APIs
Confluence does not have a mechanism to gradually rollout these changes. To reduce impact on our support teams we are planning to offset the rollouts for Jira and Confluence. Confluence is currently confirming their roll out date but tentatively targeting 100% roll out on 2019-05-29T16:00:00Z.
Roll out status updates
I will use these weekly update posts to provide ongoing status updates for the roll out and to inform you if anything changes.
Communicating to our customers
Many of you have commented that you haven’t seen much in the way of communications to our customers for these changes yet. We have been finalizing the customer facing messaging for the roll out of Profile Visibility Controls which is tentatively targeted for roll out at the end of May.
The API deprecation roll out which was described in the “Roll out Plan” section above is separate set of changes to the launch of profile visibility controls. We may have caused some confusion including the testing for profile visibility controls in our weekly status update posts. To clarify, the roll out of new APIs is largely the removal of username and user keys from our REST APIs (the changes described in the API Migration guides). The user object returned with accountID will not change, meaning all fields will continue to be passed.
For the API deprecation, we are preparing our cloud support teams with the following messaging:
Customers with user installed apps may experience error messages or reduced functionality.
Error messages may occur if legacy user references (e.g. usernames or user keys) are still being used by the app because our cloud REST APIs no longer accept or return these references.
In some cases, historical configurations like post functions or scripts may have stored a legacy user reference (username or user key) which could not be updated to accountID during the migration window (October - April 2019). In those cases, a workaround may exist to re-save the configuration to overwrite the legacy user reference with accountID. It is best to work with the app vendor directly to identify any workarounds to complete migration. Additionally, some apps may no longer be able to provide localization functionality or present the same context as the host application because timezone and locale were removed from context parameters. Context parameters are additional information sent to apps via URL.
Similar messaging will be made available via our public knowledge base and in our customer community.
Additionally, our support team will continue to direct questions we receive about apps directly to the app vendor. Typically this is done by providing a link to the app listing in Atlassian Marketplace with the support tab highlighted. We recommend updating your app listing to provide a link to your own support documentation on this page (especially any documentation containing guides for completing the migration). If you’d like to share your documentation with us so that the support team can share on your behalf please raise a DEVHELP ticket.
Thank you
As always, thank you for working with us through these changes. Its been a large amount of work to complete in a short timeframe and we appreciate you helping us deliver a more trusted experience for customers.
