I’m using the ‘Get users in organization’ method in the servicedesk API as documented here. (although the same goes for any other method that should, according to the docs, return e-mail addresses)
The example result shows a field emailAddress, however this field is missing in the response I get from this method.
As suggested elsewhere I checked the global setting User email visibility which is set to Logged in users only but the results are the same when set to public.
The user I’m connecting with also has the Browse users and groups permission.
Somehow the emailAddress field went missing in all API calls in the last few days suggesting it is because of some setting that was changed but I can’t figure out what setting is responsible for this.
Can anyone give me insight in why this field is (suddenly) missing from my API results? (and on how to get it back since its vital to our synchronization logic)
The missing field(s) are by design; it's not a bug but a choice made to comply with GDPR. Individual users can choose to disclose their email through the API but this means some will and some wont. A new API will be added in the future where you can get a list of all e-mails, however this requires whitelisting of your application. If this change breaks your code, then the only solution is to change the logic OR use the new API (when its available) OR have all your users disclose their email. For more information, see the links in the official answer below.
This change is related to:
More details about this change have been shared in the developers community:
Please review above 2 threads in community.developer.atlassian.com and add your questions to there, if any.
Hi @AIO Support ,
I can see that this question has already been answered in the support ticket you have created for this issue:
[...] we’re gonna add (in a few days) a flip switch for each user to choose the visibility of their email address. [...]
Also, if this is very urgent for you and you need to have a workaround applied, I have been told that there should be a way to temporary disable this, even if it is not advisable. Please discuss this option with the support engineer handling your ticket since if you really cannot wait.
I hope this helps.
@AIO Support It really depends on your case. We were using emailAddress to link user accounts between JIRA and our system. After some research we decided to replace it by Atlassian Account ID. You can find more here https://developer.atlassian.com/cloud/jira/platform/deprecation-notice-user-privacy-api-migration-guide/. I hope this would help.
In short: the missing field(s) are per design to comply with GDPR. So the fields are gone and will remain gone. Users will be able to allow you to use the fields, however this is per user so might not be useful for everyone. (if you synch users then you need ALL emailAddresses, not just some)
There will be a new API that allows you to get the addresses, however you will have to get white listed for it. (Your app needs to comply to GDPR basically)
In all other cases you will need to find a new way to do what you want to do. We are now experimenting with account Id's instead which is a pain but for now should work. But miles may vary depending on needs.
I think that even though it was communicated it was done in a poor fashion; at least put this information in the API documentation since that is the goto source for all developers. But it is what it is I guess ;)
Yes, thank you @Roel Abspoel for the concise explanation.
"the fields are gone and will remain gone"
"need to comply to GDPR for whitelist api"
"communicated in a poor fashion".
This gives a direction for how to fix - re-code. The emailAddress was the only link we had between jira and our local system for matching up users, so now we need to figure out something else - during the outage this caused.
I'm still waiting for Jira support to get back with me, and hopefully confirm this info.
I see you have a ticket open with Jira Support on this but, as written on the bottom of the Guidelines for Testing Profile Visibility Controls thread, it would be best to open your request with the Developers Support team instead:
Raising issues with Atlassian
I hope this helps.
Please notice that this change has been actually announced in different places and emails have been sent to all the admins:
Also, as advised, we are now adding all the relevant documentation to the REST API pages. This is now mentioned on the top of the already provided threads in the developers community:
Note: These guidelines are still being drafted and when finalized will be published in our developer documentation. This information is subject to change. We wanted to get this information to you as soon as possible, even in draft state, to help better prepare you for testing.
Finally, be also aware of the below bugs when handling non-managed users that have just been reported:
Hi all! We’re interested in learning more about your ITSM practices - what’s the current state of your ITSM practices? What are your aspirations for your IT team in the future? Which ITSM trends ar...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events