Update on the roll out of new Bitbucket Cloud, Jira Cloud and Confluence Cloud APIs
Bitbucket APIs Bitbucket APIs are rolled out to 100% of Bitbucket apps.
Jira APIs There was an issue shutting down the whitelist last week for Jira, so some developers who were on the whitelist may have seen username and userkeys still appearing in some webhooks. The issue is expected to be resolved which means that once again, Jira APIs are rolled out to 100% of Jira apps and the Jira SOAP APIs have been shut down.
Confluence APIs The new Confluence APIs are now rolled out to 100% of apps and customers. The SOAP APIs were temporarily shut down this week and then turned back on due to an issue with Jira. The new target date for shut down of our SOAP APIs is TBC.
On launch of Profile Visibility Controls
ACJIRA-1878 has been resolved and rolled out to 100% of production instance. Users should now be able to search by exact match on email address.
Profile visibility controls will roll out to 100% of Atlassian accounts on 2019-07-14T14:00:00Z. We started gradual roll out with Jira users last week.
As a reminder, profile visibility controls will allow users to control their profile settings through Atlassian Account. Certain fields like timezone and email address may be hidden by a user and not return in the user object. Additionally, the user may decide to show only public versions of their name or avatar.
All of these changes including the default settings are documented in these guidelines .
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.
Please confirm /user endpoint should not have emailAddress field neither for everyone visibility no private.
After my profile been updated I can not receive emailAddress no matter of privacy settings.
@avelit - There is a 5 min delay for profile visibility settings changes to be reflected in the API. Can you confirm if when setting your email address to public you are still not seeing it in the API (after 5 mins) and which API you’re using?
@akassab: can you speak to the status of the Jira REST APIs, as connected via a user/API token rather than via an app)? They are currently in a bit of a mixed state, for instance:
/user/search returns old-style data (including usernames)
/users/search returns new-style data (accountID only)
/issue/<issue_id>/changelog returns authors with old-style data (including usernames)
@EliDaniel - I’ll have to check on /user/search and /issue/<issue_id>/changelog since what you’re describing is unexpected. Usernames and user keys should have been removed and replaced with accountID regardless of auth mechanism.
In terms of the application of profile visibility controls, the set of data returned when an API token is used is similar to a user session, whereby the user who’s API token you’re using will have their private data returned (as if they were looking at themselves) but public data for everyone else. Apps can only see public data.
The limitation with using an API token instead of an app is that if you were to want to access private data (e.g. email addresses for other users on your system) for the purposes of syncing users across systems, we would not be able to provide access to the restricted email API (described here).
Hi,
We have an issue which I think is directly related to this.
We have been using the /rest/api/3/group/member?groupname=confluence-users API call to return users in a specified group (e.g. confluence-users)
We see that since this change, we only see the email addresses of users on our site that relate to our organisation (which has been domain claimed in Access). email addresses of external users are not visible.
As the organisational and site administrator, how do we get around this as all our internal recharges and billing breakdowns are dependent on the email address of the site users (both internal and external).
We need to continue using the REST APIs.
What is the solution as the users of our sites are not EU based at all so it’s debatable at a site level as to whether any of the GDPR should apply in our case?