[Episode 12] Ever Tried to Find Every Jira Project a User Can Access?

[#1]

Holaa Community peeps!

There’s a Jira admin question that sounds incredibly simple:

“Can you tell me which projects this user has access to?”

For one user and one project, that's usually manageable. But when someone asks you to check this across dozens of users and hundreds of projects, things can get messy pretty quickly. 😅

However, Jira does give you a ways to investigate this today.

For a quick check, you can use “Log in as user” to see what a particular user can access. You can also look through their groups, project roles and permission schemes to understand how that access is being granted.

If you're comfortable with APIs, you can take this a step further with Jira's REST APIs and pull information about users, groups, project roles and permissions. With some scripting, you can build your own report showing which users are connected to which projects.

That's probably the most flexible approach if you have a technical team that can maintain it.

But, the original question that got me thinking about this was essentially:

“I have 70 users. Do I really need to check every project one by one just to find out what each user can access?”

That's exactly the kind of scenario we had in mind when we built Access Reviewer360. The idea is pretty simple: pick a user and see all the projects they can access, or pick a project and see which users have access to it, all from one place.

For smaller Jira environments, the native options may be more than enough. But when the number of users and projects starts growing, having everything in one view can make these checks a lot easier.

I'm curious how other Jira admins handle this today, especially if you're managing hundreds of projects. Are you using automation, REST API scripts, spreadsheets, or something else?

[Ballon Apps]

This is a common pain point, and the native options you listed (Log in as user, REST API scripting) are the right starting point for smaller instances.

Disclosure up front: I build Jira apps too, including one in this space, so take the below as one vendor's scar tissue rather than a neutral review.

The thing that cost me the most time: role membership alone is not the full picture. On a real project I measured, the permission scheme granted BROWSE_PROJECTS to an applicationRole with no parameter — "anyone holding a Jira licence" — while the project's roles contained two apps and no people. A review built on role membership showed no human users at all for a project every licensed user on the site could open. Confident and wrong is the worst thing an access review can be.

So if you're evaluating any tool for this (mine included), the question I'd ask is: does it read the permission scheme itself, or only role membership? And Ananjan, genuinely curious rather than rhetorically — does Access Reviewer360 resolve scheme grants as well as roles? The article doesn't say, and it's the detail I'd want to know as an admin.

If you're rolling your own scripts, the grant types worth resolving are more than most people expect: projectRole, group, applicationRole, anyone (anonymous access, including logged-out visitors — the single most important row a review can carry), user, projectLead, assignee, reporter, userCustomField, groupCustomField, and sd.customer.portal.only. Anything you don't recognise should be surfaced, not dropped — an unexplained grant is exactly what a review is for.

One honest caveat on that advice: expanding group grants into their members needs manage:jira-configuration, which is a heavy scope to ask for. My own app deliberately doesn't do it — a group grant shows as one row with the group name, with a banner saying members aren't listed. That's a real limitation, not a feature, and worth deciding consciously either way.

My app is User Access Review for Jira on the Marketplace if you want something pre-built, but the scheme-vs-roles gap above is worth checking whichever route you take.

[James Woyciesjes]

I addressed this thru multiple different scripts:

Jira / Confluence Admin Tool
==============================
1) Projects by User (≈35 min): What projects a user is a member of
2) Groups by User (≈1 min): What groups a user is a member of
3) Groups by Prefix (≈1 min): We have multiple divisions so find all groups that start with a certain prefix
4) Projects by Group (≈35 min): What projects a group is assigned to
5) Filters & Scrum quick filters (field) (≈1–5 min): IF you rename/delete a field, project key, find where it is used (JQL statements)
6) User by Group (≈1 min): Create a list of all users in a group
7) Filters — permissions for user or group (≈1 min): List out permissions that a user/group have for Filters they have access to
8) Filters — full permission inventory (≈1 min): Similar to 7 but includes sharing settings