You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I'm a longtime admin, but I've always been careful with my groups, so I've never run into this before.
I recently inherited a second instance of Jira from another division of my company. The previous "admin" had not enabled any kind of security; he was essentially a billing contact. Almost every user in the instance had full admin access (which I shut down immediately!) and they were liberal, to say the least, about creating groups.
I'm now trying to figure out what these groups do... Only 5 out of the 100+ groups are providing product access. Is there any way to audit where the other groups are used?
For example, some kind of report that would show me that group A is in the People section of projects 1, 2, and 3, and group B is used in workflow conditions or validators in projects 4, 5, 6.
We are on Premium, if it makes a difference. I'm also willing to install an add-on if there's one that will help.
At Atlassian Teams 22 there was a vendor who had a marketplace app called Glass Project and I think this is it: Glass Project Documentation for Jira | Atlassian Marketplace
What it does is exports all project info into documents like pdf and Confluence. I think it also did others like Excel.
You might be able to export all projects and compile a list of which projects has which groups.
If I had your task this is where I would start.
Not an easy task done manually, but create dashboard with all the projects (to get visibility) and check each project one by one.
If projects are company managed, you can check the permission schemes. Gives some breadcrumbs.
Import all the users with the groups to check where the users are and if there is any activity on the permission group. Easiest to close down groups and projects where activity is zero.
I am in a similar boat where I was "voluntold" to be the Atlassian Admin after years of dozens of people having admin access. So we have a couple hundred Jira Groups when we really need 10-15 at most.
The info you are looking for is not really available via the web application interface. You can get most of this using the REST API, but it is not easy because you need to do it backwards.
By backwards I mean can't get a list of where a Group is used. You can get Project Role assignments, which will list Users and Groups. But you need to get this for all Projects and then process the data to get the info by Group. The same applies for filter sharing.
I do not know if you can get Workflow Group usage via the REST API.
There might be some addons that could help, but not being allowed to have any addons I haven't looked.
This takes multiple steps.
First you need to get the Project Roles for each Project. You can get this a couple of ways. I use the Get Project API, because I want the additional info it provides. You should also be able to get it with Get project roles for project as well.
The JSON that is returned has a REST URL for each Role in that Project. If you execute that URL it will give you a list of the Groups and individuals that are assigned that Role for that Project.
Ravi Sagar has a good video on YouTube about this.
To get the info you really want you have to do a lot of REST calls and then massage the results to get the data you really want. I am working on a system that pulls data using many REST calls across Jira, Confluence and Bitbucket. Then put it in a database where the business folks can regularly run user access audits that are required for us by either regulation or contract.
Note, I am using Jira Cloud. Data Center or Server might be different.
I think that is part of the blessing and curse of there being a REST API. Sure, you can get a lot of data using it, but it makes for a lot of work to do it.
Larger companies can afford to have a bunch of admin staff and/or addons. A small organization can more easily gather the data manually. But as a medium sized organization, that is very budget conscious, it is really annoying to not have an admin data export and/or reporting toolset of some kind. Good thing I have a programming background from decades ago to fall back on. I'm still trying to figure out efficient ways to read and manipulate the JSON results.
I use python and API calls to export the information I am looking for - Issue Filters currently. And then import that into Powerbi to parse the data. When I get time I plan on adding additional objects like dashboards and project settings. Postman is a good tool to work with the API and provides code examples for several programming languages.
I've checked quite a few places and the best answers I can find are these.
1. There is a long painful query sort of solution: https://confluence.atlassian.com/jirakb/how-to-identify-group-usage-in-jira-441221524.html
2. There is a ticket requested to add this functionality to Jira but is not being worked on yet: https://jira.atlassian.com/browse/JRACLOUD-71967
Seems like the best way to go unfortunately is the manual route.
I would almost just think about filling in the projects with the proper groups then going back and wiping out the manually made groups. We use Active directory in our company and imported those groups to Jira, but we did have some groups that were made by another admin and some Users that were specifically listed on projects that we are cleaning up.
Thanks, @Brian Selewski Unfortunately the direct query solution is only possible on server/data center. We're on cloud.
I can certainly go that manual route, although I'd prefer not to. My main concern with that, though, is user-owned filters and dashboards. Now that the ability exists for a user to add editors to their filters and dashboards, many of them are using the existing groups for that purpose. I really don't have the time to go through hundreds of them one by one, and I can't tell my users that things are going to break unless they change all of their owned elements.
We are currently doing a review of Groups to see what we can get rid of. The filters are a big bump in the road. We have almost 3000 of them to check, before removing a group.
This is one of a number of big reasons I am learning about the REST API. There is just no other way to gather the data needed in a timely and not too expensive manner.
Right now in cloud there is no way to audit groups like there is for roles. This is a thing I have to deal with regularly.
Best is to track down groups manually see where they may be applied or not. I know that if you only have 5 that do product access then those can be kept.
Its a battle at this point with groups.