How to restrict users from creating tickets

[Jen-Qology]

We are attempting to change user permissions limiting those that can open and update tickets.

Please assist, thanks

[Deleted user]

No problem, define a group that should be able to create and edit issues, then set just that group for the project create and edit capabilities. See here for more information;

https://confluence.atlassian.com/jira/managing-project-permissions-185729636.html

[Jeff Foss]

Tom - I need to stop a certain defined group of users from creating issues in various projects, but I still need them to be able to comment on existing issues in those projects. Doable?

[Nic Brough -Adaptavist-]

Don't give them "create issue" in the projects, but still let them have "comment"

It's all in the permission schemes, as Tom's link says.

[Jeff Foss]

Thanks for the quick reply Nick! Let me see if I'm understanding correctly. It looks like I could create a new permission scheme and exclude this group from the "Create Issue" permission setting. Accurate?

The challenge I see is this seems to be based on inclusion rather than exclusion. In other words, I'd have to list every single group that does need to be able to create issues (about 30) and exclude the one group that doesn't. Furthermore, as we add new people and groups to JIRA, I'd have to remember to come back and add those groups to this one specific permission scheme. Does all of that check out with you?

Screen Shot 2016-04-27 at 12.02.56 PM.png

[Nic Brough -Adaptavist-]

>It looks like I could create a new permission scheme

Yes

>and exclude this group from the "Create Issue" permission setting

No.  As you say, it's all about inclusion, not exclusion. 

I would also do it entirely with roles, rather than groups, so you can reuse the permission scheme, AND delegate the maintenance to the project owners.  You'll need a permission scheme that allows you to not let people in at first and then add the people you do need as you go.


What I would do (for a cut down list of actual permissions here) is something like:

• Admin project: role - project admins
• Browse project:  role - users, role - viewers
• Create issue: role - creators, role - developers
• Edit issue: reporter, assignee, role - developers
• Resolve issue: reporter, role - developers

and so-on

You still use the groups here - you add them into the roles with in the project, rather than having to add all of the individual users.  But a different project can have different users and groups in the project.  This scheme can be used once, for many projects, and when new people start, or people leave, your project admins can update the project.

You are right in that you'll need to look at the thirty-ish groups who should have access, but it's a lot easier to add them to roles en-masse than it is add them into a permission scheme.