The App "Issue Type Filters" might help you

working cross project with multiple teams and disciplines and you only want specific teams and/or roles to be able to create certain issue types becomes a multiple workflow nightmare.

Abstract example:
users primarily working on project can create all issue types

users external to project:
user A can create issue type A and X and Z
user B can create issue type B and X and Y and Z
user C can create issue type C and Y and Z

Workflows to accommodate:

workflow(s) for regular issue type(s)
separate workflow for issue type A ( user A )
separate workflow for issue type B ( user B )
separate workflow for issue type C ( user C )
separate workflow for issue type X ( user A, user B )
separate workflow for issue type Y ( user B, user C )
separate workflow for issue type Z ( user A, user B, user C )

it only gets worse the more complex this structure needs to become, this is a simple example.
The administrative overhead to manage these workflows, and the risk of making a mistake increases exponentially as more issue types and conditions have to be accounted for.
A simple control to dictate who can create what eliminates this administration and security headache entirely

For us it would be really helpful to restrict the creation of epics in certain projects to a group of user or project role. A validator function for the create issue transition is necessary and we were wondering why it's not implemented yet.

Hello, I can't understand why Atlassian ignores all useful request and implement random and useless features. It looks like they want their partners sell more paid addons that covers basic needs ( basic querying, reporting, managing rights for creating some issue type....). Atlassian boord runs this company as if it is Ryanair.

While waiting for this functionality to be available in Jira out of the box, maybe you could consider the app we developed - Field Rules for Jira. It includes the Hide issue types rule, which enables you to hide specific issue types on the Global Issue Create view. Moreover, you can configure preconditions based on user groups, project roles, or individuals. I would appreciate it if you could give it a try.

i found a quick and dirty workaround : create an empty screen, attribute this screen to "create" for your restricted issue type, none can create since there isnt any compulsory field filled

they can still go around this by cloning or re-using an existing issue of that type but the "can't create, missing summary" message can serve as a soft warning to prevent the mistake

Hello Everyone,

If you are having scriptrunner, in your workflow update parameters of the 'ScriptRunner Script' Validator for "Create" transition.

Restrict to User Groups

 
user.groups.includes('usergroup')

Our pain point is to be able to block the creation of Stories for specific teams.

The suggested workaround is horrible from many aspects. 

9 years with no traction on a basic ask, typical of Atlassian

The workaround is horrible; nothing prevents the user from filling out the create form, only to receive an error message upon submit.

This is SIMPLE: you already have the capability to define the validator rule - QUERY THE RULE WHEN DRAWING THE CREATE SCREEN.  

For each IssueType in Project

Hi,

We have Projects configured with issue types starting from,

Level 1 - Objectives,

Level 2 - Initiatives,

Level 3 - Epics,

Level 4 - Stories, Defects, Problem etc

Level 5 - Subtask

So in a Project we don't want all to create Objectives and Initiatives. How can we restrict this?

I hope this is basic requirement.

+1 so strange this is not implemented yet. 9 years, Atlassian please...

Like many others - we really need this sooner than later

Any movement on this? I see some tickets were closed. Is there a new ticket? 

+1

We really do need this ASAP

+1

+1

+1

+ 1

+1

Wow created since 2015

Table stakes....ship it!

We need this feature!

+1 please

+1 please

It is WILD to me that a software management tool does not allow it's users to remove over 50+ options on issue types! This is incredibly inefficient for organizations to create seamless workflows and does not help analyze the data and collection of metrics!! In addition, the 50+ issue types are so complex, tt can take up to 2 minutes just finding the right issue types for our teams.  Come on, Atlassian. Do better. 

We should have this feature implemented. Certain teams do not need all the issue types while creating tickets. This will help to reduce unnecessary noise during project execution.

In my opinion, this is not a suggestion, but a clear bug of certain priority. If Jira offers functionality to restrict a specific issue type to some user, it has to care about in any situation – also when creating a new issue. This use case equally has to be considered in a secure permission concept and should be ensured automatically, i.e. without need of any additional configuration step by administration.

Realmente necesitamos esta característica en Jira Cloud, hace poco estaba intentando crear un proyecto para una gran cantidad de colaboradores de la empresa y me encontré con ese muro.

We need this feature as well!!
If you work together with a lot of people on one Jira Project, there are all different types of lets say expertise levels on there. So it would be great to be able to restrict issue types to certain groups. Super helpful as well when working with external service providers. 

I need this! 
How can this made any progress?

Thanks

Gathering interest since 2015???

we need this feature!

Please prioritize this request!!! It's very inconvenient to have to create a separate project for different Issue Type permission. 

I was very surprised to find that this functionality is missing.

I used the process outlined by @Erol Yoes which at least restricts the creation of issues, but the Type is visible to all users which is far from ideal. The workaround is also clumsy and relies on having a spare permission.

We have our Jira projects organized by releasable products encompassing just about everything related to said product, making this project inherently cross-functional.  We have use cases for certain teams to create certain issue types for certain other teams.

It would be nice to be able to outright restrict certain teams to only use issue types that apply to them (for example, a TAM shouldn't be able to create Epics or Stories, or SQL change, and other unrelated issue types to them that exist in the project), rather than keeping a master document of who should use which issue type when and hope that everyone views it regularly and follows it.  Bonus points for removing those unrelated issue types from those users in the create screen.

I am also open to suggestions if perhaps there is a better way to utilize Jira for cross-functional collaboration.

Waiting anxiously for this to be developed and released!  We really need it to work in harmony with automation rules we've built to automatically create sub-tasks (preventing users from manually creating them by role).

maybe this helps a bit.

Not the best cleanest Solution, but in base to me its good enough for now.

• for Restricted Issuetypes, create a sepperate Workflow
• create a group  with members which should be able to crreate the issuetype ( not members of it, will not be able to create the issuetype)
• search for an unused Permission in Permission Scheme of the project. in our case i used the "Issue Security" there you add your group.
• add a Validator to the "Create" Transition.
• select " Permission validator" and set permission "Set issue Security"
• Publish Workflow and have a try.

make sure Issue Security is not used in the project

This is so basic need and am very disappointed that there is no such feature. It is badly needed.

We all need this ! Please implement it.

This feature is really needed and helpful for organizing backlog. Can someone respond that when can we expect this feature for team-managed project?

I have a use case for Software-related projects where we use Epics, Story, bugs and sub-tasks as issue types.

We are looking to grant "QA Tester" project role or Group the ability to create only bugs based on their QA findings.
For now this seems to be an all-or-nothing permission. 

Hopefully we can see changes for this piece in the near future. Thanks ^Erik

it's quite useful if user group can be used to restrict Jira creation by type.

Thanks  a lot!

Agreed.  I have a number of non-IT based users where I only want to them to see specific issue types so it doesn't cause confusion for them and the rest of my team to have FULL access to all issues.

https://getsupport.atlassian.com/browse/JST-781027

Please add this feature, was sure we had it until under the hood :-/

I agree with Henry Chad Apale : even the Conditions tab should suffice.

But right now, there's nothing...

It would be of the great help for all Jira users to have an option to restrict issue creation of a specific Issue Type to a limited Jira group or project role. Since moving to Jira Cloud is no longer optional, is having this option too much to ask?

Hello there,

I recently noticed that it team-managed projects you can restrict issue type for certain roles: 

Hope this helps.

For those of you interested in getting this ability, they just created a ticket based on the bug I reported yesterday: https://jira.atlassian.com/browse/JRACLOUD-76362

Since you got rid of the of the Group permissions in the Validator functions this has become quite critical for projects with several stakeholders managing different issue types.

Please, give more importance to this topic as it impacts Team managers and Jira admins time with no ROI actions when it comes to have an organized and controlled backlog.

Please add back the ability to validate if a user is part of a specific user group before the creation of a specific issue-type (or in a specific workflow).

The current validator pertaining to the user's Permissions is not enough to prevent more user groups from having the ability to create issues. We require more, even the Conditions tab should suffice.

This should be a basic function
 

This is required for the kind of setup we have in our organization.

This is absurd that Atlassian still cannot fix this. This is such a basic problem to be fixed