To clarify the deprecation of AP.get.userTZ() this will not include un-deprecating timezone and locale in Context Parameters because the data is passed by URL. We are requiring apps to make an explicit request for this personal data should they need it.
To clarify migrations with atlassian-connect-express (“ACE”), theres a new method available for user impersonation, asUserByAccountId() , which will work with accountIDs instead of user keys. If necessary, apps may use the new migration endpoints to convert stored user keys to accountIDs first and then use the asUserByAccountId() method.
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. Last week we communicated that this work was expected to be complete at the end of next week, however our dates have slipped and our current estimate is 28 Feb 2019.
Issues with updating data stored in product - As mentioned in last week’s post, Jira has already released a new endpoint which will be unaffected by the 29 Mar 2019 deprecation (see: /rest/api/3/bulk/migration). Confluence expects to release a similar endpoint in two weeks time.
Conversion of stored CQL containing legacy user references to accountID - The Confluence team is aware that this is an issue. They may be considering developing a similar solution to the PD Cleaner provided by Jira. We will provide more details next week on the status.
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.
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 next week.
Regarding the issue with the Jira PD Cleaner recognizing issue entity property aliases, the Jira team has committed to working on this issue. We don’t have a confirmed date yet but will provide an update on status next week.
Regarding the issue with ACJIRA-1625, we are currently looking into the status of that issue and will provide more detail within the week.
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.
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.
In addition to the status update above @akassab has also posted a blog post on the developer blog outlining the State of Atlassian Ecosystem changes to address privacy.
We’re looking to get a better understanding of which apps are not ready for the deprecation of username and user key, so if you are blocked by one of the issues highlighted above please update your Atlassian Connect App descriptor with the opt in flag set to “false”.
Any chance you plan to share a recording of the webinar that happened the other day? I got some highlights from another dev but would like to review in full.
Hi @akassab - we can’t update our descriptor to have “gdpr: true” because we expose the content of webhooks directly to customers for them to interact with and we need to wait for all of them to update any relevant scripts that rely on the current user objects inside those webhooks. However, we have migrated our services to stop storing userkey/usernames and we no longer rely on their existence.
At the moment we (ScriptRunner Cloud) are blocked by “Jira PD Cleaner recognizing issue entity property aliases” and “CQL PD cleaner”… we are actively working on a nasty workaround for migrating post-functions.
Edit: we’re also blocked by having the user type (addon or not-addon) in all the various APIs and webhooks etc so we can make sure we dont try and impersonate another addon
@jbevan - Jira has confirmed that they will pick up work on the issue entity property alias problem next sprint and anticipate it to be fixed within 2 weeks time. I’ll update via the weekly post if anything changes. The webhooks problem is also being resolved. I’m told by the Jira team that webhooks both contain accountID and account type in production now (confirming if the docs have been udpated).
I’m still waiting on confirmation of the CQL PD cleaner from the Confluence team. Confluence webhooks are also being updated but I’m not sure if they changes are yet live in production. Will confirm in this week’s post.
In terms of opt in, I understand you can’t set the flag to true. Could you set the flag to false to signal that you are blocked? This shouldn’t affect the behavior of the APIs.
I suppose you require apps to do an explicit request for this data so you can better record what app is accessing it. Would you consider making these two explicitly requested context parameters (not sent by default, but only if asked for in the URL template string in the app descriptor)? This way you could still record it.
With the current state we’re forced to either block displaying the UI until the request is loaded or to change locale (and this means UI i18n) after our UIs got the response. This would result in either a slow UI or in a UI that briefly after loading suddenly changes its language.
Using the browser’s information from the Accept-Language header and the JS Date object would be possible but would result in app iframe UIs behaving different from the Confluence UI - after all not every user has their language settings set to ‘auto-detect’.
This is also a performance issue for static macros.
Hi,
We have another question. We are wondering whether it is possible to retrieve our own Addon’s accountId from a reliable source?
As you mentioned, the accountId is the same across all Jira Cloud instances. Currently in our first drafts of GDPR compliance we make use of the /myself endpoint authorized by the JWT method which seems to be properly returning the accountId of our Addon user. The problem is, however, that we can only do this when the first instance sends us a request so that we can ask this particular instance for those details.
This of course does not feel right, is error-prone, unreliable and random. Furthermore, it forces us to work around proper multitenant architecture internally. We would love to see a single resource/microservice or generally something Jira Cloud instance-independent that we could ask about our Addon’s accountId in runtime. Is it possible? What would you recommend?