My company has multiple Jira projects set up for the product areas. As the company is growing rapidly, an issue we are finding is that users outside of the team are creating issues in the said Jira projects, when they shouldn't, as this is no longer the process for reporting issues and/or requesting new features.
Out of the nearly 300 users we have, we'd like to limit the creation within those Jira projects, about 5 or 6 of them, to approximately 50-60 only.
How can I do that? Had a hard time looking for this in the permissions section.
Thank you.
This is always a problem as you scale up, but the obvious answer is the starting point for the discussions.
The defaults in Jira are "everyone can do most things". It's open, collaborative and a total nightmare the instant you want to have control over who does what.
The short answer to your question is just "look at the permission scheme. Who has 'Create isssue' permission?"
Hello @barbara_santos
Hope all is well and welcome to the community.
As was stating using the permission scheme to help allocate who can create issues is very effective. If your using Jira software projects then probably best to limit that unless users are trained where to enter tickets.
What you can do in the permission scheme is create a group with specific role. In Atlassian admin users & Groups create the group to add users to project then put that into the project as a specific Role. Make sure when adjusting the permission scheme to add this Role to the permission scheme for create issue. Remove other Roles from that so the new group now has that project permission create issue which is matched to the role. You can create new roles in Systems settings under the Roles tab.
For ease of management and future growth using groups in permission schemes can make life hard later and really not best practice. Groups can be used to give project permission of access and then tie it to specific Role to get the permission they need. If you have so many project you could adjust this for all projects by using the same permission scheme for all them and add the group and role to each project. The other thing this will do is still allow users to interact on tickets just not create issues.
I hope this helps.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I think using groups in permission schemes is a bad idea. Moreover I recommend removing all groups and individual users from permission schemes. Roles is what should be used.
1. Make a role Issue Creators.
2. Remove any users and groups from Create Issue permission in permission scheme
3. Add Issue Creators to this permission
4. Add specific users (or groups) to this role on People folder in project settings.
This way you will only need one permission scheme for all projects. And every project will have special people that can create issues.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
setup a group for each project and put that group in the create issue permission. Then remove the logged in user from that permission
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Barbara,
I had the same request come in and this especially is important on our side for our vendors accessing our boards.
We created a GROUP that supports those who should be limited in what they can and cannot do which then lead into a ROLE inside of Project Boards. Anyone added to that GROUP would have that specific ROLE in specific Projects.
Hope this helps!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@barbara_santos - Just chiming in on this one. Nikki seems to be the only one that has also mentioned Roles.
This can come down to the size of your organisation and relative technical understanding of the tool within your company.
Broadly from my experience:
Groups
Generally good to setup business areas, teams or "disciplines" within the company in order to manage the sharing of Filters, Dashboards, Boards and Notifications.
E.G. Setting up a "Sales" group for your sales team so you are able to share your customer support monthly dashboards with them
Roles
Useful to setup and define specific roles within a given project and allow a specific project Administrator for the project to add users to those roles for that project.
E.G. Create a "Tester" role who you can then both set permissions in the permissions scheme AND assign specific people with Jira accounts to that role on a per project basis (via a given projects: project settings > people)
FYI - Roles are shared across the entire instance so perhaps some standardisation could be wise here!
Overall groups is how I started with permissions/notifications but Roles I feel is a more robust solution and avoids your Jira admins constantly amending group memberships for what is essentially Project Role assignment.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I guess you need to add that roles help to standardize projects permissions. One can have a single permission scheme that suits any project. And then assign users to roles on this project.
E.g. you have one project for Middleware and another for Frontend.
Developers role can be assignable, work on issues, browse and so on
QA role can create issues, transfer them, add attachments and so on
Supervisor role can schedule issues, assign users and so on.
For Middleware project you add MW developers to developers role and their scrum master as supervisor.
For Frontend you add FE developers to developers role and their scrum master as supervisor.
They share same QA team as QA role.
Easy - you have set permissions once and forever and don't need to dig into it every time you have new project. Moreover there are no monstrous groups like ALL DEVELOPERS and users only have access to information they need.
The last thing to say is that devs from frontend will not see MW tickets in search and vise versa. This improves productivity.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Recommended Learning For You
Level up your skills with Atlassian learning
Learning Path
Become an effective Jira admin
Manage global settings and shared configurations called schemes to achieve goals more quickly.
Streamline Jira administration with effective governance
Improve how you administer and maintain Jira and minimize clutter for users and administrators.
Learning Path
Become an effective Jira software project admin
Set up software projects and configure tools and agile boards to meet your team's needs.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.