I’m on the JIRA GDPR team and I’ve added a ticket to my teams backlog to see if we can add this information to the jira rest api (no commitment that we can at this stage though). It sounds like something we’d want to do, but doing so would probably be a while away as it requires some dependencies to be complete that aren’t there yet.
@david2 if you want to use GDPR mode in the meantime a workaround is to use the email address as this shouldn’t be hidden for app users.
1 Like
@hday I think from an efficiency usage perspective it would be best if you could include in the webhook payload (or http headers) - don’t make us have have more latency than necessary (and add an extra hit to your services).
2 Likes
@hday thanks for the workaround. Is it safe to assume that any email address @connect.atlassian.com will be an add-on (app) user?
@david2 yes, it should be safe to assume that. I don’t believe anyone else would be able to make an account with that email domain, and all Connect apps have that email domain.
1 Like
We are currently making this assumption internally in jira. Can’t guarantee that that won’t change in the future, but it seems unlikely to.
1 Like
@hday And by the way, why doesn’t the authorization server (auth.atlassian.io) simply reject requests to create an access token for an add-on user other than the current app’s add-on user? This way, we would have a clear and consistent error beforehand, which could be handled directly in Atlassian Connect Express (in internal/oauth2.js).
Please note that the structure of the email address ...@connect.atlassian.com is an undocumented feature and is subject to change without any notice.
Please also note that, there are other types of system/app users (that are not related to Connect users), for which this trick won’t work. For example if a 3LO app does things via an API call, the corresponding user won’t have an email address to check against.
Therefore, providing extra information about the “type” of the user (by Jira and Confluence) is probably the most reliable way to address this situation, in the webhook payload and/or in the user fetch API. This information is available in the underlying Identity API, but unfortunately it is not passed on to the apps by Jira/Confluence. Even if it is only provided in the fetch API, you can cache this information for a fairly long time since the type of user is not likely to change at all.
Hi @natashbar,
Are you saying we should not heed to the advice the other Atlassians gave here? But then, what should we do? Can you commit to providing a solution like the one you described in time for us to implement the GDPR migration in due time? We are already completely in the dark as far as configuration migration is concerned (migrating post-function configurations in workflows), and the clock is ticking…
1 Like
Hi David,
What I am saying is that, heed that advice by all means but be aware of those caveats. I could see us providing a more reliable solution, but we (different teams in Atlassian) haven’t yet agreed on the solution yet since this topic was brought up only recently. I will be following that up with Jira and Confluence teams and get back to you. I shared some information about the internal state of things (so you are not kept in the dark), which could have caused confusion at the same time. The good thing is we have a work-around, chances are we can get a proper solution out in time.
Regards,
Norman
Hi everyone,
We discussed this internally (among Connect, Jira, and Confluence) and a decision was made to provide an extra parameter in the webhook payload to help identify the type of the user account. More information will be provided as soon as it is implemented.
In addition to that, in the second stage, that information will also be available in the user fetching API, in case it is needed for other use cases.
We will post an update here once the new parameter is available for webhooks.
Regards,
Norman
3 Likes
Hi @natashbar, that’s great news. I assume that the extra parameter will also be included in post-function /triggered calls, since they use the same webhook machanism, right?
Would you have a JRACLOUD or ACJIRA ticket for that implementation that we can follow?
Regards,
David
@natashbar can you confirm whether this change will also be added to the user picker REST API or do I need to raise a new ACJIRA ticket for that?
Please raise a separate ACJIRA ticket for that.
To give you a bit of update, the accountType field should now available in the body of Confluence webhooks. We are still waiting for the work in Jira to complete.
@natashbar can this change (accountType) be reflected in Find User API as well
‘/rest/api/3/user/search’ . Will it be covered in this ticket https://ecosystem.atlassian.net/browse/ACJIRA-1686 or do we need to create a separate ticket for this.
We need to be able to identify the add on user so that we can filter them out and show only actual users. We wont be able to use User Picker API as it doesn’t include user email address in the response.
Thanks!!
Please make app’s account id to be the same for all host instances.
Especially that we would not be able to find our own addon users by username anymore.
Would we need to search the app user by email address per host in order to know the corresponding app account id?
I have also raised a separate ticket to return this field in the user fetch API. I just made https://ecosystem.atlassian.net/browse/ACJIRA-1714 to track it. You can expect this to be updated when the new field is available in the API. It might be a duplicate of https://ecosystem.atlassian.net/browse/ACJIRA-1686 , as I don’t know what you meant by user picker API.