Uploaded image for project: 'Jira Platform Cloud'
  1. Jira Platform Cloud
  2. JRACLOUD-72483

REST API endpoints that return user objects leave email field blank for unmanaged users

      Issue Summary

      Any Jira Cloud REST API endpoint that returns user objects in the JSON response will return a blank email address for any non-managed users. This happens regardless of if they are set to "Public" or "Private" in the Atlassian Account privacy settings (which do not have the email address specific setting for non-managed accounts).

      Steps to Reproduce

      1. Invite an unmanaged user to your instance if one does not already exist
      2. run /rest/api/3/user/search?query=<email address of user>

      Expected Results

      The returned user object email field is populated with the expected email address

      Actual Results

      The email address field is returned with an empty string as the value

      Workaround

      Currently, there is no workaround.

            [JRACLOUD-72483] REST API endpoints that return user objects leave email field blank for unmanaged users

            Filippo added a comment -

            I am experiencing this issues as well, but only in few cases. The user did not restrict visibility of the email, yet I get 

            "emailAddress":""

             

            I cannot find the difference with other user profiles which work fine.

             

            Filippo added a comment - I am experiencing this issues as well, but only in few cases. The user did not restrict visibility of the email, yet I get  "emailAddress":""   I cannot find the difference with other user profiles which work fine.  

            Greg D added a comment -

            Yesterday, this seems to have reverted to blocking portal-only email addresses again.  We believe that it started around 8 hours ago in our instances.  We need to be able to grab the issue.fields.reporter.emailAddress via API.  Users should also be able to see those email addresses in the UI.

            Greg D added a comment - Yesterday, this seems to have reverted to blocking portal-only email addresses again.  We believe that it started around 8 hours ago in our instances.  We need to be able to grab the issue.fields.reporter.emailAddress via API.  Users should also be able to see those email addresses in the UI.

            Likely due to settings when testing. Changes have been made since this issue was reported. 

            Peter Weinberger added a comment - Likely due to settings when testing. Changes have been made since this issue was reported. 

            Hi ben.slade, greg.draper310998593

            It looks like there is a problem with gsync on your organisation that is causing the problem where users authenticating with different auth mechanisms can't see email addresses. This should be fixed shortly, someone from our identity team is going to reach out to your gsync site admins via email. Apologies for the confusion that has caused.

            Cheers,

            Harry

            Harry J.E Day 🔓 (Last Day 21st July) (Inactive) added a comment - - edited Hi ben.slade , greg.draper310998593 It looks like there is a problem with gsync on your organisation that is causing the problem where users authenticating with different auth mechanisms can't see email addresses. This should be fixed shortly, someone from our identity team is going to reach out to your gsync site admins via email. Apologies for the confusion that has caused. Cheers, Harry

            Hi ben.slade

            Thanks I will get those accountIds looked at and we can see what's going on there.

            For #1, apologies my reply to Greg was incorrect (there was some confusion internally). If an email address is set to "only me and admins" the email can only be seen by admins in the usermanagment console. You might be able to use the usermanagment api though ( https://developer.atlassian.com/cloud/admin/user-management/rest/). My reply to Andrey was correct. Sorry for the confusion.

             

            Hi akiyanovskiy

            ScriptRunner is a connect app and they run under different rules. I've asked someone from our ecosystem team to reply to you with more information.

             

            Harry J.E Day 🔓 (Last Day 21st July) (Inactive) added a comment - Hi ben.slade Thanks I will get those accountIds looked at and we can see what's going on there. For #1, apologies my reply to Greg was incorrect (there was some confusion internally). If an email address is set to "only me and admins" the email can only be seen by admins in the usermanagment console. You might be able to use the usermanagment api though (  https://developer.atlassian.com/cloud/admin/user-management/rest/ ). My reply to Andrey was correct. Sorry for the confusion.   Hi akiyanovskiy ScriptRunner is a connect app and they run under different rules. I've asked someone from our ecosystem team to reply to you with more information.  

            Hi Harry,

            Thank you for the information. I think we have an issue with the user we run REST API calls under. User related events in ScriptRunner can't be run on behalf of a user, only under ScriptRunner user. But ScriptRunner user has always been an admin and should have access to all information as admins by default. It looks like if you were asking each and every our admin user to sign a legal agreement with Atlassian. Why can't we tell by ourselves who should have admin permissions?

            Andrey Kiyanovskiy added a comment - Hi Harry, Thank you for the information. I think we have an issue with the user we run REST API calls under. User related events in ScriptRunner can't be run on behalf of a user, only under ScriptRunner user. But ScriptRunner user has always been an admin and should have access to all information as admins by default. It looks like if you were asking each and every our admin user to sign a legal agreement with Atlassian. Why can't we tell by ourselves who should have admin permissions?

            Ben S added a comment -

            Hi Harry Day, 

             

            In response to your followup questions for Greg above - I can provide answers there. I've just run the same calls and experiencing the same problems that he is referencing: 

             

            For #3 the user doing the request is AccountID: 557058:5415f2c8-d88a-406c-9746-30f202baf67c (an organization admin user) and the user I'm requesting is AccountID: 5bb37d9ee441cd77203a8c2f  (email visibility is set to organization) 

             

            For #1 in your comment back to Greg you said "only organization admins can see email address in rest apis." in both cases we are requesting from an organization Admin user so according to your answer it should return the email address of those users (with visibility set to only admin and me) but it does not.

            It also seems like you told Greg one thing and then told  Andrey the opposite with your last sentence in your last comment.

             

            Ben S added a comment - Hi Harry Day,    In response to your followup questions for Greg above - I can provide answers there. I've just run the same calls and experiencing the same problems that he is referencing:    For #3 the user doing the request is AccountID: 557058:5415f2c8-d88a-406c-9746-30f202baf67c (an organization admin user) and the user I'm requesting is AccountID: 5bb37d9ee441cd77203a8c2f  (email visibility is set to organization)    For #1 in your comment back to Greg you said "only organization admins can see email address in rest apis." in both cases we are requesting from an organization Admin user so according to your answer it should return the email address of those users (with visibility set to only admin and me) but it does not. It also seems like you told Greg one thing and then told  Andrey the opposite with your last sentence in your last comment.  

            Hi akiyanovskiy

             

            Replying here so that others looking for information might find it as well.

             

            We can't include email address in webhooks because webhooks are not authenticated as a user and thus we're legally obligated to only return public data.

             

            When you make the call to the rest API are you authenticated as a user or a connect app? Connect apps can only get public data unless they apply for an exemption through our legal department (due to gdpr rules).

             

            You may also be running into the problem that user profile data is eventually consistent. It can take up to 5m for email address to populate. You will be able to tell if this is the case because the user's display name will be "Failed to retrieve user <aid>".

             

            Finally admins can only get access to "only me and admins" email addresses in user management not the rest API. You might be able to use the user management API if the accounts are all managed accounts ( https://developer.atlassian.com/cloud/admin/user-management/rest/#auth)

            Cheers,

            Harry

            Harry J.E Day 🔓 (Last Day 21st July) (Inactive) added a comment - - edited Hi akiyanovskiy   Replying here so that others looking for information might find it as well.   We can't include email address in webhooks because webhooks are not authenticated as a user and thus we're legally obligated to only return public data.   When you make the call to the rest API are you authenticated as a user or a connect app? Connect apps can only get public data unless they apply for an exemption through our legal department (due to gdpr rules).   You may also be running into the problem that user profile data is eventually consistent. It can take up to 5m for email address to populate. You will be able to tell if this is the case because the user's display name will be "Failed to retrieve user <aid>".   Finally admins can only get access to "only me and admins" email addresses in user management not the rest API. You might be able to use the user management API if the accounts are all managed accounts (  https://developer.atlassian.com/cloud/admin/user-management/rest/#auth ) Cheers, Harry

            Hi Harry, it seems like the email address is not available only for just created users in the user_created event handler. Please refer to PSCLOUD-31259.

            Andrey Kiyanovskiy added a comment - Hi Harry, it seems like the email address is not available only for just created users in the user_created event handler. Please refer to PSCLOUD-31259.

            greg.draper310998593 for your last problem (number 3) could you give me the Atlassian account id of the user doing the request and the user you are requesting? We are looking at options for number 2 and that will be addressed in the JSDCLOUD ticket. For 1 only organisation admins can see email address in rest apis  admins can only see email addresses in the user management console (edited, apologies original response was incorrect)

            akiyanovskiy can I ask more information about your use case as a quick test worked for me, but I may be doing something different:

            • What form of authentication are you using to make the request/is your request being made in a connect app?
            • What is the privacy settings of the user account you are looking up? (and what is the account id)
            • Is the user you are using to do the lookup an organisation admin (and what is there account id). Also are they a managed account in the org?

             

            Harry J.E Day 🔓 (Last Day 21st July) (Inactive) added a comment - - edited greg.draper310998593 for your last problem (number 3) could you give me the Atlassian account id of the user doing the request and the user you are requesting? We are looking at options for number 2 and that will be addressed in the JSDCLOUD ticket. For 1 only organisation admins can see email address in rest apis   admins can only see email addresses in the user management console (edited, apologies original response was incorrect) akiyanovskiy can I ask more information about your use case as a quick test worked for me, but I may be doing something different: What form of authentication are you using to make the request/is your request being made in a connect app? What is the privacy settings of the user account you are looking up? (and what is the account id) Is the user you are using to do the lookup an organisation admin (and what is there account id). Also are they a managed account in the org?  

            Greg D added a comment -

            Here are some examples of different API calls that are not working Harry (number 2 is most important since there is not even a setting for those users and we need to grab them much more often due to Jira Service Desk deficiencies):

            1. ...atlassian.net/rest/api/2/issue/<issue id> will not show email address for all users (managed nor unmanaged) that have their setting as "Only you and admin" even for site admins (nor the admin of the entire instance nor admins of the project)... it will only show if they have it as Public
            2. ...atlassian.net/rest/api/2/issue/<issue id> will not show email address for a portal-only customer in any scenario (the only places email address is shown for these users is in the Customers section and in the User Management of https://admin.atlassian.com for your instance.... but no way to know which issues they are associated with) - this one is the most critical to fix -  https://jira.atlassian.com/browse/JSDCLOUD-8289
            3. ...atlassian.net/rest/api/2/issue/<issue id> will also not show the email address for managed users if they are a part of your Organization, have their profile set to that Organization for visibility, and your admin user uses a separate Identity Provider (e.g. admin uses G Suite and the user uses Okta)... even though the entire instance is a part of the organization you cannot make any users outside of the single Identity Provider a part of that visibility

            Greg D added a comment - Here are some examples of different API calls that are not working Harry ( number 2 is most important since there is not even a setting for those users and we need to grab them much more often due to Jira Service Desk deficiencies ): ...atlassian.net/rest/api/2/issue/<issue id> will not show email address for all users (managed nor unmanaged) that have their setting as "Only you and admin" even for site admins (nor the admin of the entire instance nor admins of the project)... it will only show if they have it as Public ...atlassian.net/rest/api/2/issue/<issue id> will not show email address for a portal-only customer in any scenario (the only places email address is shown for these users is in the Customers section and in the User Management of https://admin.atlassian.com  for your instance.... but no way to know which issues they are associated with) - this one is the most critical to fix -   https://jira.atlassian.com/browse/JSDCLOUD-8289 ...atlassian.net/rest/api/2/issue/<issue id> will also not show the email address for managed users if they are a part of your Organization, have their profile set to that Organization for visibility, and your admin user uses a separate Identity Provider (e.g. admin uses G Suite and the user uses Okta)... even though the entire instance is a part of the organization you cannot make any users outside of the single Identity Provider a part of that visibility

            Hi Harry,

            I need to check if the user's email address belongs to managed accounts. But '/rest/api/3/user?accountId=<id>' doesn't return email even for managed accounts. May I ask why we don't have permissions to see this info?

            Andrey Kiyanovskiy added a comment - Hi Harry, I need to check if the user's email address belongs to managed accounts. But '/rest/api/3/user?accountId=<id>' doesn't return email even for managed accounts. May I ask why we don't have permissions to see this info?

            Hi guys if your issue is NOT the issue in the issue description (search for exact email which should be working) can you please comment here what api you are using and what your use case is?

            Harry J.E Day 🔓 (Last Day 21st July) (Inactive) added a comment - Hi guys if your issue is NOT the issue in the issue description (search for exact email which should be working) can you please comment here what api you are using and what your use case is?

            Greg D added a comment -

            Hey everyone,

             

            This bug was a problem on day 1 where it wasn't even honoring the Public setting in both the API and UI (maybe the settings were misaligned as it was replicating)... at least via API you were always able to grab managed users as an Admin (apps were the ones running into problems).  The remaining issue with this is in the UI, where admins still cannot see an email address for users on the Only you and admin setting.

            But the much bigger problem is more focused on the JSD portal-only customers where you cannot even grab their email via API (regardless of whether you are an admin or not).  Everyone, please go vote on this one:  https://jira.atlassian.com/browse/JSDCLOUD-8289

            Greg D added a comment - Hey everyone,   This bug was a problem on day 1 where it wasn't even honoring the  Public  setting in both the API and UI (maybe the settings were misaligned as it was replicating)... at least via API you were always able to grab managed users as an Admin (apps were the ones running into problems).  The remaining issue with this is in the UI, where admins still cannot see an email address for users on the Only you and admin  setting. But the much bigger problem is more focused on the JSD portal-only customers where you cannot even grab their email via API (regardless of whether you are an admin or not).  Everyone, please go vote on this one:    https://jira.atlassian.com/browse/JSDCLOUD-8289

            Hi m.assaf.byd

            Can I just confirm that in your case you are searching for an exact email address, and getting a result for that user. But the result does not contain the email address of that user?

            If so that is the expected behaviour. I know that's a bit weird, but that is due to privacy control requirements. If you know an email address of a user exactly we are allowed to look them up for you, but we can't return you the email address of the user.

            Can I ask what your use case is here for needing the email in the json given you just requested it with the exact email?

            Harry J.E Day 🔓 (Last Day 21st July) (Inactive) added a comment - Hi m.assaf.byd Can I just confirm that in your case you are searching for an exact email address, and getting a result for that user. But the result does not contain the email address of that user? If so that is the expected behaviour. I know that's a bit weird, but that is due to privacy control requirements. If you know an email address of a user exactly we are allowed to look them up for you, but we can't return you the email address of the user. Can I ask what your use case is here for needing the email in the json given you just requested it with the exact email?

            it does not work for us, I've invited unmanaged user, and searched for the exact email ID, I got nothing in the JSON response for emailAddress. we provision users using REST API and they do not change the default value what ever it is for privacy!

             

            Mohammad Assaf added a comment - it does not work for us, I've invited unmanaged user, and searched for the exact email ID, I got nothing in the JSON response for emailAddress. we provision users using REST API and they do not change the default value what ever it is for privacy!  

            Hi guys. I'm a developer in the Jira GDPR team.

            If your issue is specifically around service desk customer accounts could you please move to https://jira.atlassian.com/browse/JSDCLOUD-8281 so we can separate the two issues.

            If you are finding that you can't get email of a normal user who has set their email to public (and you've waited 5 minutes after the change was applied) can you please comment the api you are calling here?

            Can you also please check that you are changing the setting on a page that looks like this:

            We expect that the specific example in the issue description `/rest/api/3/user/search?query=<exact match of email address of user>` should work for an exact match, regardless of privacy settings. Please comment here if that is not working for you.

            Due to GDPR legal requirements we can't give users access to another user's email address if they have set it to private.

             

            Harry J.E Day 🔓 (Last Day 21st July) (Inactive) added a comment - Hi guys. I'm a developer in the Jira GDPR team. If your issue is specifically around service desk customer accounts could you please move to https://jira.atlassian.com/browse/JSDCLOUD-8281 so we can separate the two issues. If you are finding that you can't get email of a normal user who has set their email to public (and you've waited 5 minutes after the change was applied) can you please comment the api you are calling here? Can you also please check that you are changing the setting on a page that looks like this: We expect that the specific example in the issue description `/rest/api/3/user/search?query=<exact match of email address of user>` should work for an exact match, regardless of privacy settings. Please comment here if that is not working for you. Due to GDPR legal requirements we can't give users access to another user's email address if they have set it to private.  

            Same as above, it is a breaking change.

            Romain Regnier added a comment - Same as above, it is a breaking change.

            Greg D added a comment -

            To echo Andreas, this is breaking change for Jira Service Desk.  Please go mark this issue as affecting your team and mention it in your Support issues too:  https://jira.atlassian.com/browse/JSDCLOUD-8281

            They are related, but slightly different since portal-only customers do not even have an Atlassian profile (and they shouldn't have one... we should be able to fully control them as our own customers keeping their names and passwords synced via a separate Identity Provider from that of our internal employees... keeping their display names and passwords updated/synced).  So I'm worried if only this piece gets fixed, the portal-only customers will remain broken since it has failed to get identity love.

             

            On top of the bug, this setting should work as a global default that Admins can control and then users can change from there (I know this is tough since profiles are global... but it should live in the G Suite config, the Atlassian Access config, and then for portal-only customers in the instance config or even project so that we can control how the visibility starts for new users).

             

            Greg D added a comment - To echo Andreas, this is breaking change for Jira Service Desk.  Please go mark this issue as affecting your team and mention it in your Support issues too:   https://jira.atlassian.com/browse/JSDCLOUD-8281 They are related, but slightly different since portal-only customers do not even have an Atlassian profile (and they shouldn't have one... we should be able to fully control them as our own customers keeping their names and passwords synced via a separate Identity Provider from that of our internal employees... keeping their display names and passwords updated/synced).  So I'm worried if only this piece gets fixed, the portal-only customers will remain broken since it has failed to get identity love.   On top of the bug, this setting should work as a global default that Admins can control and then users can change from there (I know this is tough since profiles are global... but it should live in the G Suite config, the Atlassian Access config, and then for portal-only customers in the instance config or even project so that we can control how the visibility starts for new users).  

            Our whole JSD Workflow relies on "Reporter E-Mail Address", we are automatically linking Support Cases through E-Mail Address by REST API to our CRM, to our Billing Solution, PBBX Caller Info for current Issue Status, and so on and on and on ...

            Currently our whole Support Workflow is broken because of this ... Those are the Bugs driving Management into dropping Atlassian Products in favor of other Solutions ... so please get your things together and fix this FAST ... and not the "Atlassian Style" ... within the next 7 - 12 Years ...

            Andreas Schnederle-Wagner added a comment - - edited Our whole JSD Workflow relies on "Reporter E-Mail Address", we are automatically linking Support Cases through E-Mail Address by REST API to our CRM, to our Billing Solution, PBBX Caller Info for current Issue Status, and so on and on and on ... Currently our whole Support Workflow is broken because of this ... Those are the Bugs driving Management into dropping Atlassian Products in favor of other Solutions ... so please get your things together and fix this FAST ... and not the "Atlassian Style" ... within the next 7 - 12 Years ...

            @Ben We are actually referencing users in Jira/Service Desk, both bugs seems related. but this one is highly impacting my business and could possibly unblock yours.

            It is hard to rely on the service for integration and promis your customers with something if you do not know the resolution timeframe at least, we need to hear back from someone here on workaround or timeframe so we can know how to reply to our customers as well. 

            Mohammad Assaf added a comment - @Ben We are actually referencing users in Jira/Service Desk, both bugs seems related. but this one is highly impacting my business and could possibly unblock yours. It is hard to rely on the service for integration and promis your customers with something if you do not know the resolution timeframe at least, we need to hear back from someone here on workaround or timeframe so we can know how to reply to our customers as well. 

            Ben S added a comment -

            @Mohammad we are in the same boat today. If you are using Jira Service Desk and relying on referencing the Service Desk Customers (portal only customers) its probably because of this bug ticket, take a look and give it a vote if you are impacted by this too: https://jira.atlassian.com/browse/JSDCLOUD-8281

             

            If it is only internal users that you are looking at here you may be able to fix this by directing users here https://id.atlassian.com/manage-profile/profile-and-visibility and having them update their Email visibility setting to "Anyone". 

            Ben S added a comment - @Mohammad we are in the same boat today. If you are using Jira Service Desk and relying on referencing the Service Desk Customers (portal only customers) its probably because of this bug ticket, take a look and give it a vote if you are impacted by this too:  https://jira.atlassian.com/browse/JSDCLOUD-8281   If it is only internal users that you are looking at here you may be able to fix this by directing users here  https://id.atlassian.com/manage-profile/profile-and-visibility  and having them update their Email visibility setting to "Anyone". 

            This is impacting our customers, we have other system integrated with Jira highly relies on this field. currently we have an outage on all our services as a result of this bug

            Mohammad Assaf added a comment - This is impacting our customers, we have other system integrated with Jira highly relies on this field. currently we have an outage on all our services as a result of this bug

            "The email address field is returned with an empty string as the value" I was directed here by Atlassian support. I am experiencing something slightly different, the JSON does not have an empty string for emailAddress, the field is simply completely absent.

            Vincent Castellano added a comment - "The email address field is returned with an empty string as the value" I was directed here by Atlassian support. I am experiencing something slightly different, the JSON does not have an empty string for emailAddress, the field is simply completely absent.

            Greg D added a comment -

            Thanks, Belto.  Unfortunately on top of this bug that was not even honoring the privacy setting, the additional problem is that for Jira Service Desk customers (portal-only customers), there is now no way for agents in the UI or for the API to see their email address.  There is no such setting for their email address visibility.  So basically JSD is fully broken.

            Greg D added a comment - Thanks, Belto.  Unfortunately on top of this bug that was not even honoring the privacy setting, the additional problem is that for Jira Service Desk customers (portal-only customers), there is now no way for agents in the UI or for the API to see their email address.  There is no such setting for their email address visibility.  So basically JSD is fully broken.

            Belto added a comment -

            There is a guidline on requesting the email address for unmanaged users

            Belto added a comment - There is a guidline on requesting the email address for unmanaged users Guidelines For Requesting Access To Email Address

              Unassigned Unassigned
              jlong@atlassian.com Jared Long
              Affected customers:
              31 This affects my team
              Watchers:
              36 Start watching this issue

                Created:
                Updated:
                Resolved: