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; } } }

How to limit users who can create an issue?

barbara_santos

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.

Comments

Dan W_kamf5a

setup a group for each project and put that group in the create issue permission. Then remove the logged in user from that permission

Nic Brough -Adaptavist-

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?"

A A Ron Geister [Trundl]

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.

Sergei Gridnevskii

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.

Nikki DuBois

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!

Lewis Cook_vntdgk

@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.

Sergei Gridnevskii

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.

Welcome!

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