nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

The API for searching for users with viewing permission is not working correctly

Nikita Grishin_6aqn6q

We've configured "Issue Security" in Jira Cloud, so some issues are only visible to the "Administrator" role.

If you check through the UI, everything works correctly; users with other roles don't see the issue.

However, when using the API (https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-user-search/#api-rest-api-3-user-viewissue-search-get), the "Find users with browse permission" section specifies "returns only the users from that range that match the search string and have permission to browse issues."

However, in our case, when calling the API, users are returned even if they don't have access to a specific issue.

Accepted answers

All comments

Trudy P Claspill

Hello @Nikita Grishin

Welcome to the Atlassian community.

I don't think that API endpoint takes into consideration Issue Security. It talks only about having the Browse Projects permission. It does not say explicitly that they must not be otherwise blocked from seeing a specified issue.

Either an issue key or a project key is required as input so that the API can identify the project that needs to be checked.

This was documented as a known bug in the same API for Jira Server/Data Center. The issue does not include a link to a comparable bug for Cloud.

https://jira.atlassian.com/browse/JRASERVER-76439

You could ask your Jira admins to raise a support case with Atlassian Technical Support to find out if this is a known bug for Cloud also.

Arkadiusz Wroblewski

Hello @Nikita Grishin

What you’re seeing is pretty consistent with how Jira Cloud behaves here: Issue Security is working, but that particular user-search endpoint is not a reliable “who can see this specific issue” check.

Why the UI is correct but the API returns “too many” users

Jira visibility is basically:

Project permissions (Browse Project) AND Issue Security level (if set on the issue)

The UI applies both, so non-admin roles don’t see the secured issue — correct.

But GET /rest/api/3/user/viewissue/search is described as “users who have permission to browse issues”. In practice it often behaves like a project-level browse permission check, and doesn’t fully respect issue security level visibility when you expect it to. So it can return users who can browse the project generally, even though they can’t view that particular secured issue.

What to do instead (depending on what you actually need)

If you need to know whether a specific user can view a specific issue The only reliable test is to check visibility as that user:

Try to fetch the issue as that user (it will be hidden if they lack access), or

Use a permission/visibility-aware approach in the user’s context.

If you need a list of everyone who can see the issue There isn’t a single clean “list viewers” REST call that always works with Issue Security. You typically have to compute it:

Read the issue’s security level (security field).

Resolve the members of that security level (roles/groups/users in that level).

Combine that with project browse permission.

PS: the “security level member” APIs are much nicer in company-managed projects; team-managed projects can be more limited.

Nikita Grishin_6aqn6q

Hello @Trudy P Claspill

"It talks only about having the Browse Projects permission." - This is controversial because the API description states “have permission to browse issues"

And the API request accepts a specific issueKey. Here's an example request:
https://our-jiraserver.atlassian.net/rest/api/3/user/viewissue/search?&issueKey=TEST-25&query=%25&maxResults=100&startAt=0

I'll ask the Jira admin to create a case about this, thank you.

Arkadiusz Wroblewski

@Nikita Grishin

Please let us know about answer you get from support, API Endpoints are very living environment, especially since latest 2 Years changes which have very Big impact on many things.

Nikita Grishin_6aqn6q

@Arkadiusz Wroblewski Thanks for the reply. I assumed that's how it behaves, but it seemed very strange to me. Especially considering how difficult it is to assign different permission levels in Jira. After all that, you want to send an API request and see a limited number of people for an issue, but it returns everyone)

Trudy P Claspill

@Nikita Grishin

You are correct; I misquoted the documentation.

However, it is the Browse Projects permission (in a Company Managed project) that enables a user, at the project level, to "browse issues: within the project.

Arkadiusz Wroblewski

@Nikita Grishin

Totally fair point. After doing all the work to configure Issue Security, you expect an API called “users who can view this issue” to return only the people who can actually see it.

I’m not going to be too critical of Jira’s permission model though.

It’s one of the few platforms that gives you this level of granular control. The catch is that some endpoints only check project-level “Browse” permissions and don’t fully account for issue security, while the UI applies the full visibility rules. That’s why the API result can look “too broad” even though the UI behaves correctly.

Also… this is why “Atlassian admin” is kind of a joke title now. At this depth, we’re really acting as systems/identity engineers.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

rest-api

api

jira-service-management-cloud

jira-service-management