Hi @natashbar,
first of all, I don’t think that having to make an extra call to the Jira REST API is a good thing - Atlassian is trying to reduce the number of calls apps have to make to function (c.f. the GraphQL initiative), and now you’re saying we should increase it…
Then, I tried to call the (Jira) /rest/api/2/user endpoint for our addon user, and the response did not include an account_type field:
{
"self": "https://innovalog.atlassian.net/rest/api/2/user?accountId=557058:472c64c9-2567-4213-839b-86bf21558300",
"key": "addon_com.innovalog.jmwe.jira-misc-workflow-extensions",
"accountId": "557058:472c64c9-2567-4213-839b-86bf21558300",
"name": "addon_com.innovalog.jmwe.jira-misc-workflow-extensions",
"emailAddress": "com.innovalog.jmwe.jira-misc-workflow-extensions@connect.atlassian.com",
"avatarUrls": {
"16x16": "https://avatar-cdn.atlassian.com/7dc7b05da33fdf03bcef359457ceb3f0?s=16&d=https%3A%2F%2Fsecure.gravatar.com%2Favatar%2F7dc7b05da33fdf03bcef359457ceb3f0%3Fd%3Dmm%26s%3D16%26noRedirect%3Dtrue",
"24x24": "https://avatar-cdn.atlassian.com/7dc7b05da33fdf03bcef359457ceb3f0?s=24&d=https%3A%2F%2Fsecure.gravatar.com%2Favatar%2F7dc7b05da33fdf03bcef359457ceb3f0%3Fd%3Dmm%26s%3D24%26noRedirect%3Dtrue",
"32x32": "https://avatar-cdn.atlassian.com/7dc7b05da33fdf03bcef359457ceb3f0?s=32&d=https%3A%2F%2Fsecure.gravatar.com%2Favatar%2F7dc7b05da33fdf03bcef359457ceb3f0%3Fd%3Dmm%26s%3D32%26noRedirect%3Dtrue",
"48x48": "https://avatar-cdn.atlassian.com/7dc7b05da33fdf03bcef359457ceb3f0?s=48&d=https%3A%2F%2Fsecure.gravatar.com%2Favatar%2F7dc7b05da33fdf03bcef359457ceb3f0%3Fd%3Dmm%26s%3D48%26noRedirect%3Dtrue"
},
"displayName": "Jira Misc Workflow Extensions",
"active": true,
"timeZone": "Europe/Berlin",
"locale": "en_US",
"groups": {
"size": 3,
"items": [
]
},
"applicationRoles": {
"size": 2,
"items": [
]
},
"expand": "groups,applicationRoles"
}
I still believe this information should be passed to apps without requiring an extra call.
Finally, we use Atlassian Connect Express, and it could also handle whatever is required to identify add-on users when calling the “asUserByAccountId()” method - for example as part of the impersonation token acquisition. Basically, if the impersonated user is unacceptable (because it’s an add-on user), it should revert to no impersonation.
Am I missing anything?