Grant "Browse Users" permission to add-ons requesting READ scope

Description

Currently, add-ons don't automatically get the global "Browse Users" permission, which is needed to get data from:

  • /api/{v}/user/search

  • /api/{v}/groups/picker

  • /api/{v}/user/permission/search

Environment

None

Activity

Show:
Fernando Boucquez (PPL)
October 5, 2018, 11:57 AM
Edited

Has this been fixed? Our addon's backend can now search users using just JWT token (before all the user searches returned an empty list). Has anything changed in your end?

Adam Wride
June 7, 2017, 5:37 PM

Not sure why an add-on with the following scope: "Read data from the host application" wouldn't be able to browse users.

I imagine most of our users expect that the add-on can read JIRA user data having granted that scope.

Mark L. Smith
August 17, 2016, 5:39 PM

We're impacted by this issue as well.

We'd be fine with a new scope – BROWSE_USERS – to request to get access to these user search APIs.

Brendan Patterson
November 18, 2015, 10:13 PM
Edited

This accounts for the vast majority of my support requests for Cloud right now. It is super confusing for the users when someone else updates permissions for the space and all add-ons stop working.

This is literally the perfect of example of if Atlassian were building commercial or supported Cloud add-ons (dogfooding) for JIRA and Confluence .... this would be implemented. Hipchat add-on devs won't run into issues like this because Atlassian is dogfooding Hipchat AC for add-ons they support.

Yves YANG
June 4, 2015, 7:34 AM

Hi,

We have the same problem with /rest/api/2/user/permission/search. Please increase the priority!

Assignee

Unassigned

Reporter

Patrick Streule