In order to improve security guarantees on the Get User REST API endpoint in Jira Cloud, this endpoint will now require the calling user to have the Browse Users and Groups permission to be able to access results. We are updating the API to enforce this requirement.
What this means for Apps?
If your app is accessing the endpoint using User Impersonation then the user that is being impersonated will require the browse users and groups permission to access this endpoint going forward.
This means that if your app used this functionality, and your users have restricted browse users and groups permissions, they may notice a change in the way your app behaves. You should ask them to request the administrator gives their user browse users and groups access in Jira global permissions.
If your connect app is accessing the endpoint using the Application User the app will continue to require READ Scope as is currently the case, and you will not see any difference to how your app functions.
This change is now available to all who have signed up for Jira Cloud Vendor First Release Group.
If youâd like to see these changes on your instance first, before they go out to customer instances, please ensure you are enrolled in the Jira Cloud Vendor First Release Group - you can sign up here.
Iâm not trying to be a pain but another thing I need to sign up for? While I canât speak for other vendors all I want is:
A) be able to have one instance that has all upcoming potential changes that might break me as soon as itâs available.
B) one instance that gets the changes first when things roll out.
This sign up for this, oh sign up for this is seriously worrisome. It seems to be a lot of waste of everyoneâs time to me (both mine and Atlassianâs)
Edit: the above stuff had rant tags.
Now to this change - will this be documented somewhere? Will a user be able to look up their own group?
If you already have an instance you signed up on the Ecosystem Beta Group list then this Jira Cloud Vendor First Release Group is the same thing. Our apologies for that not being clear. There was a rename of the list recently to better align that itâs not beta functionality youâre signing up for but to be in the first cohort of the release.
How about until Atlassian can give us a reliable platform to understand what youâre shipping to our instances, you put breaking changes on hold?
Use the functionality being built for Enterprise Cloud, show us what features are enabled on our instances, allow us to toggle them, we need to be able to test various combos. This whole process weâre dealing with is ridiculous. Would Atlassian accept this type of behavior from AWS as a platform vendor?
Edit: before you give me a generic âweâre working to make things betterâ response again, hereâs a question:
How many changes requiring opt-in have you rolled out in the last 3 months? How many of them were breaking? If this is hard to answer, then you have a serious problem. Weâre talking basic change logs here.
And think back to how the CSAT numbers are trending.
We do have a meeting scheduled for the end of next week about a working escalation path with @WarrenChen who has been great about setting that up at our request.
This need was known but made all the more evident by such a roll-out which broke two of our top apps for 9 hours. It took two hours to get Atlassian attention.
I state this here as a specific example and extra reason to freeze breaking changes.
Currently we are using /rest/api/2/user?accountId={accountId} with user impersonation in several places to get the information about the current users (where accountId parameter is set to the current accountId). Theoretically we could replace it everywhere with /rest/api/2/myself but it would be nice if you could allow user requests for impersonated users when they request information about themselves.
We have similar scenario as @raimonds.simanovskis. We are making /rest/api/2/user?accountId={accountId} and /rest/api/3/user?accountId={accountId} call at multiple places as an add-on. AccountId - is the currently logged in user. We are using atlassian-connect-sprint-boot/ atlassian-connect-express framework for our apps. Will the add-on be able to get currently logged in user information via above API?
Thanks @rwhitbeck couldnât have put that better myself.
Weâll be using (and re-using) this vendor first release group for all Jira releases so yâall get updates FIRST, so if youâre not already signed up please get yourself signed up.
If you are signed up then you donât need to do anything.
So just answered my own question (since nobody from Atlassian has spoken up). An app that has âact_as_userâ scope cannot impersonate a user and have it look up that userâs own group. Weâre going to be adding in a check in our front end that basically says âHave the admin add the permission to you or contact Atlassian Supportâ.
It would be nice though if we could get a permission that is just for browsing groups (and Iâm guessing other apps might need users browsing) since the current browse-user-groups permission is very broad (and abused by Jira itself it seems). I would put in a feature request - but not sure where (and pretty certain that it would just sit there).
Would be nice if somebody from Atlassian would speak up and how they view the impact of this change will impact apps (because I would think they can look at the traffic patterns for the data calls) as well as what theyâre doing to minimize the impact?
Or is Connect just dead? (slight tongue in cheek comment - but I am starting wonder about the investment Atlassian is doing into it).
@nmansilla since this change seems to break Automation for Jira as well - can we get an understanding on how Atlassian will be tackling the problem there so that we can follow suite?
One of our team members requested for their system to be added to Jira Cloud Vendor First Release Group but we have not heard back. Is there any process to check if this has been enabled?
Obviously I am joining to the question of @sfg: we have atlassian-connect application which provides PluginDescriptorResponse to Jira Cloud containing the field âscopesâ with the values
{ READ, WRITE, ADMIN, PROJECT_ADMIN, DELETE, ACT_AS_USER }. Our app manipulate Jira Issues (create, update, delete and assign) on behalf of the users. Also, it searches or users and gets users lists. As I understand these user search and get operations are running on behalf of the âadd-on userâ which has âADMINâ privilege. Can this app need additional âbrowse users and groupsâ privilege or an appropriate new scope to be added?
Weâre still waiting on this. Requests via the AppWeek Slack have gone nowhere. @nmansilla / @mpaisley / Not sure who else⊠This is whole process is insane.
Edit: got this resolved via AppWeek slack. I think the right approach here is donât test anything, when stuff breaks tell customers Atlassian isnât serious about supporting developers and fix in prod. Apparently our repeated feedback about the low quality of the developer experience isnât statistically significant.
Yes, we are aware of this solution. It might come up in the future, as we have yet to analyse the effort needed on that, but there are no plans as of yet for near future.