We have an app that has been allowed access to the email REST API so we’ve added the ACCESS_EMAIL_ADDRESSES scope to our descriptor. This allows us to get email addresses of users using the following endpoints:
However, we also noticed that when using the /rest/api/group/member endpoint that certain user objects contained email addresses while others didn’t. We realized that this has to do with the settings found here: Atlassian account
We played around with this and it seems that for apps with ACCESS_EMAIL_ADDRESSES the following is the case:
Setting
Get email via Group endpoint
Get email via Email endpoint
Anyone
Organization
Only you and admins
Theres two things that I don’t understand about this:
Why is the email address still accessible by my app when I choose “Only you and admins”. As an app developer, I actually consider this a good thing… but this is likely not what a user expects when they choose this setting IMO.
When I choose “Organization”, why is the email address not included in the group REST API call? I can still get it via the Email endpoint but that means I gotta make an extra REST call. Am I maybe missing something (e.g. an expand parameter?) that allows me to get the email addresses via the group endpoint in this case?
In other words, this is what I would’ve personally expected:
Setting
Get email via Group endpoint
Get email via Email endpoint
Anyone
Organization
Only you and admins
Happy to hear if my personal expectation is wrong and/or whether there’s a way to get email addresses via the Group endpoint when “Organization” is chosen.
Cheers,
Sven
Bonus question: Why is there an endpoint for getting a group via its ID but all other endpoints require group names? Would certainly love to be able to get members of a group via the groups ID and stuff like that. The way it is now, if decide to store group IDs instead of group names, I have to resolve each ID to a name first, using an extra REST call (and there’s also no bulk endpoint).
Your questions make a lot of sense and thanks for taking the time to articulate them so well. I have a couple of answers which I hope helps explain why things are this way, but bear in mind there’s quite a bit of legacy we’re dealing with so I recognise it’s not necessarily an ideal solution.
First off, a little context for the benefit of others. A couple of years ago, we modified a number of APIs to improve user privacy. During this process, we discovered quite a few apps were dependent on email addresses so we introduced the two “get email via endpoint” APIs you refer to, but made them only available for apps that have the scope ACCESS_EMAIL_ADDRESSES which requires an application and review process.
Why is the email address still accessible by my app when I choose “Only you and admins”?
The ACCESS_EMAIL_ADDRESSES scope authorizes the app to access user email addresses regardless of the user privacy settings because of the use cases identified by app developers / vendors. Product administrators are responsible for approving such apps during the installation process. As with other areas, these product administrators are acting on behalf of users and in this case it relates to whether an app can access their email addresses.
When I choose “Organization”, why is the email address not included in the group REST API call?
This is really just a ramification of the implementation. Conceivably the group endpoint could return email addresses if the app has the ACCESS_EMAIL_ADDRESSES scope, but the implementation of the APIs only allows email addresses to be returned for the dedicated email endpoints.
I suspect this is once again due to legacy. My theory is that the group name was originally the primary identifier, but later on an ID has become the primary identifier. I suppose it would be ideal if these endpoints could be updated so they accept either group name or ID much like the get issue endpoint accepts the issue key or ID.
Makes sense! In that case I think it would probably be good if the UI was updated to reflect this for the users…
Alright… In our case this means we might need to make a few thousand extra REST calls per hour to several Confluence instances which could be saved if the data was already included in the group REST call. Guess we’ll have no other choice than to accept this for now…
Agreed, this would be ideal. Since group IDs are available we’d much prefer storing groups via their ID so that just once more means more REST calls to resolve the IDs to group names and our app being considerably slower in the Cloud which I guess we have already come to accept.
Bit off topic: I must admit that I have a very hard time navigating the CONFCLOUD project so I have no idea whether tickets for both of these topics already exist in there. You seem to know your way around it pretty well, so maybe you have a tip for me how I can search for tickets like this easily? The standard Jira text search doesn’t seem to work too well for me.
