keelapps

keelapps/Guides

Which Jira projects can a user access?

Jira Cloud · Updated

A manager asks what a contractor can see before their contract ends. Security asks the same about an account that looks compromised. Jira Cloud shows who can reach a project, one project at a time, but nothing lists the projects one person can reach. This guide covers the admin screen that gets closest, a REST call that asks Jira for the answer outright, and how to find out which grant is responsible.

AccessLens, which we build, answers this too, so read the last section with that in mind. Everything before it works on any Jira Cloud site with no app installed.

The admin screen, and what it leaves out

In Atlassian Administration, open Directory → Users, pick the person, and in the Jira section of their profile choose View Jira space roles (older sites say project roles, and on sites still on the original user management the path starts at Products). Atlassian documents it in this knowledge base article.

It is the right first look, and on a site where every scheme grants only to roles it may be the whole story. It shows role membership, though, not access. A scheme can grant Browse projects straight to a group the person is in, to them by name, or to every logged-in user, and none of that is a role. In the other direction, a role the scheme grants nothing to gives no access at all, yet it still appears in the list.

Ask Jira directly

Jira already knows the answer: it works it out every time the person opens a page. The REST API lets a Jira administrator ask for it on someone else’s behalf, so you don’t have to rebuild the permission logic yourself.

  1. Get the person’s account ID. It is the last part of the URL when you open their profile in Atlassian Administration, or use GET /rest/api/3/user/search?query=<email or name>.
  2. List the project IDs with GET /rest/api/3/project/search, following nextPage until it runs out.
  3. Send them, a batch at a time, to the bulk permission check: 
    POST /rest/api/3/permissions/check
{
  "accountId": "5b10a2844c20165700ede21g",
  "projectPermissions": [
    { "permissions": ["BROWSE_PROJECTS"], "projects": [10000, 10001, 10002] }
  ]
}
  4. The response repeats the permission with the subset of projects where Jira says yes. Collect those across batches and you have the list.

Checking another person needs the Administer Jira global permission; without an accountId the call answers for whoever is signed in. Add more keys to permissions if you care about more than seeing the project: EDIT_ISSUES, DELETE_ISSUES or ADMINISTER_PROJECTS are the usual ones in a review.

What you get is a yes or a no per project. It does not say why, and a yes that comes from “any logged-in user” looks exactly like a yes that comes from a personal grant.

Working out why

The why matters as soon as you want to change something. Removing a person from a role does nothing if the same project also lets their whole group in. For each project the check said yes to, open its permission scheme, find who holds Browse projects, and match the person against each holder:

More than one of these can be true for the same project. Write them all down, or the first fix you try will not be the last.

Five things that skew the answer

  1. Product access comes first. Without access to Jira, none of the grants above apply. A person who lost their licence still shows up in groups and roles, which makes a scheme-by-scheme check look worse than reality.
  2. Shared schemes. One grant in one scheme can open every project that uses it. Count projects, not schemes.
  3. Team-managed projects don’t use the shared permission schemes. Their access setting and roles live in the project itself, so a walk through schemes skips them. The bulk check above covers them because it asks Jira, not the schemes.
  4. Issue-level security. Being able to browse a project does not mean seeing every issue in it. Security levels can hide some issues from people who can open the project.
  5. Today only. All of this describes the site as it is when you run it. The audit log keeps changes for 180 days but never records who could reach what on a given date, so if you will need the answer later, save it now.

Before someone leaves

Deactivating an account removes access everywhere at once, and after that the question “what could they see?” is hard to answer. If anyone might ask, run the check first and keep the output with the offboarding ticket. Then look at the things the permission check does not cover: filters and dashboards they own or share, boards they administer, automation rules that run as them, and any project where they are the lead. Those keep working, or break, after they are gone.

The same question about a group rather than a person is in Which Jira projects can a group access?, and running it on a schedule for an audit is in the Jira permission audit guide.

Where AccessLens fits

AccessLens for Jira reads every project’s permission scheme and roles into a dated snapshot. Explore → By user then lists the projects that person can reach, including access they hold through a group, and shows separately what every licensed user can reach. Each row names the path, granted directly or through which group, and whether through a scheme grant or a role, which is the “why” section above done for you. Because the answer is a snapshot, it is still there after the person has left, and you can compare it with an earlier one.

It does not check product access, issue security levels or the ownership items in the previous section, and archived projects are not scanned. It runs on Atlassian Forge with no external calls and is free for sites of up to 10 users.

Try AccessLens free