Hide Issue Types from Jira Create Issue Screen

[Hemanshu Sood]

Hi All,

This question has been asked multiple times in the community, is there a definite way to hide certain Issue types from the create issue screen so that the users are not able to use them?

Does anyone have a working javascript which can be used in Jira 6.4 ?

Please assist.

[Nic Brough -Adaptavist- · Accepted solution]

The answer that you would have found on all the other postings is still true.  Your options are

• Separate projects
• Ugly kludges that annoy users by stopping them creating after they've entered data so they lose it all
• Add-ons such as ScriptRunner that can amend it dynamically

[Alexey Matveev · Accepted solution]

Hello,

You can also implement this feature with the Power Scripts add-on:

https://marketplace.atlassian.com/apps/43318/power-scripts-jira-script-automation?hosting=cloud&tab=overview

You can find an example here how to restrict the issue type field:

https://confluence.cprime.io/display/TR/Forbidding+users+to+create+some+issue+types

You can also completely hide the field

[Joe Pitt · Accepted solution]

I haven't seen any solution to hide them. Just ones that will stop users from actually creating them. So the user will just be frustrated. The best solution is to put them in a different project that the said users don't have access to. Those with access to both can create a filter to include issues from both projects. 

[Payne]

If you have the ScriptRunner add-on installed, this can be accomplished with Behaviours.

https://www.adaptavist.com/blog/restricting-issue-types-with-scriptrunner-for-jira/

[Bernhard Lerchl]

Thanks for that one! It works perfectly!

[Makareswar Rout]

This worked for me and implemented. 

[Jeffrey Gordon]

After reading all the posts about how to approach hiding issue types from the drop down list, and experimenting with a few, I found the ScriptRunner Behaviour to be easiest to implement.  We simply added the below behaviour for ALL projects.  For us this is a set of issue types from an add-on that we no longer use.  This doesn't prevent users from importing these issue types but we deal with that separately.

import com.atlassian.jira.component.ComponentAccessor
import groovy.transform.BaseScriptimport static

import com.atlassian.jira.issue.IssueFieldConstants.ISSUE_TYPE

// Get all issue types in the system.
def allIssueTypes = ComponentAccessor.constantsManager.allIssueTypeObjects

// Get the issue type form field
def issueTypeField = getFieldById(ISSUE_TYPE)

// A list to add all valid issues types to for setting into the form field.
def availableIssueTypes = []

// The code below works by excluding specific issue types. Although ALL other issue types will
// be added to the availableIssueTypes list, only those that are part of the project's
// issue type scheme will actually be listed.
allIssueTypes.each { issueType ->
if ( issueType.name != "IssueType1" &&
issueType.name != "IssueType2" &&
issueType.name != "IssueType3" )
{
availableIssueTypes.add( issueType )
}
}

// Add all the available issue types to the form drop down list.
issueTypeField.setFieldOptions(availableIssueTypes)

[Sema YILDIRIM]

It works in a test environment. But it doesn't work live. Only jira versions are different. Could you help?

[Jeffrey Gordon]

We are using Jira Data Center 8.5.0 and ScriptRunner 5.6.11.1-p5.

[Sema YILDIRIM]

test environment : v8.2.1

work live: v7.10

[Jeffrey Gordon]

I can't speak for whether or not the script I posted would work in older versions of Jira and/or ScriptRunner as I don't have those versions available to test.

[QDappnet]

It works for us, thanks @Jeffrey Gordon 

1. Jira v8.5.4
2. ScriptRunner 6.0.2-p5

import com.atlassian.jira.component.ComponentAccessor
import groovy.transform.BaseScript

// Get Issue Type Field as a constant value
import static com.atlassian.jira.issue.IssueFieldConstants.ISSUE_TYPE

// Get all issue types in the system.
def allIssueTypes = ComponentAccessor.constantsManager.allIssueTypeObjects

// Get the issue type form field
def issueTypeField = getFieldById(ISSUE_TYPE)

// A list to add all valid issues types to for setting into the form field.
def availableIssueTypes = []

// The code below works by excluding specific issue types. Although ALL other issue types will
// be added to the availableIssueTypes list, only those that are part of the project's
// issue type scheme will actually be listed.
allIssueTypes.each { 
issueType ->
if ( issueType.name != "Issue_Type_To_Hide" && issueType.name != "Hide_Another_One" )
{ 
availableIssueTypes.add( issueType )
}
}

// Add all the available issue types to the form drop down list.
issueTypeField.setFieldOptions(availableIssueTypes)

[Lillian Shibata-Salley]

So sorry after trying to go through everything, currently there is no way of hiding the Issue Type in the Create Screen...

I'm trying to create a quick easy flow for some teams that there is 1 Issuetype. I have a drop down with custom type that they can change easily - so they don't have to move the issue if they want to change type.

It's just an extra field I wanted to hide upon Create ticket.

This should be configurable  like the "hide status button from create screen" that was great I can hide that.

I don't code so need a simple answer.

Thanks

[Nic Brough -Adaptavist-]

Correct, as the accepted answers already say, you can't hide things without Behaviours, or configuring your project to have only the issue types you actually want to use (configuring the project to work the way you need is the better option)

It is configurable - if you don't want them to create issues of a certain type in a project, then remove the issue type from the project, don't mess around adding hide options.  The "hide status button" is very different from issue type.

[Lillian Shibata-Salley]

Thanks - yes I understand best practices - I've been using JIRA for almost 10 years  and working with other automation tools like Serena, Mercury,  Salesforce, etc., but there are specific reasons of creating it the way I did for less steps and to make it as flexible to win users to start using it when I'm pushing against flexible feature reach solutions like SNOW and other products. If we don't show the flexibility designing outside the box and outside the out-of-box solution, they will get rid of JIRA and force us to use SNOW. I'm demonstrating the ease and flexibility and price of the tool where, at the same time, putting in the controls that are needed in this situation. It may not be much but it makes a big difference.

Atlassian shouldn't dictate and force what each company does as each company works differently and should have the ability to make our own decisions depending on the situation.

Just my 2 cents worth.

[Nic Brough -Adaptavist-]

The flexibility is there.  If you don't want to let people raise a certain issue type, don't give them the option to do it. 

I don't understand why you are not doing this.

[Lillian Shibata-Salley]

I am doing that - I'm trying to hide the field from the Create Issue screen.

[Nic Brough -Adaptavist-]

Why?  It would be confusing to users who use other projects with more than one issue type, or have used Jira before, so I do not see any good reason to do this.

[Sruthi Kumaran]

Hi 

Is there any solution available in Jira cloud version to hide/disable issue type in create screen

[Nic Brough -Adaptavist-]

We've got Behaviours in Cloud, but it does not yet work with Issue Type (Atlassian have not given us the frameworks we need to be able to do it, but we're working with them on it)

[Evgenii]

Hi, @Sruthi Kumaran 
Now it's available in cloud
https://www.scriptrunnerhq.com/inspiration/blog/behaviours-arrives-for-issue-view-plus-2-other-announcements

https://library.adaptavist.com/entity/Limit-issue-types-based-on-groups?tab=cloud

[Muhammad Akram Sharifi]

Hi,

This is not working for Jira cloud

[Nic Brough -Adaptavist-]

Cloud doesn't yet support the solutions given

[mesa sisa]

have a look here:

https://community.atlassian.com/t5/Jira-Software-questions/How-to-delete-an-issue-type-from-project-or-hide-it-from-quot/qaq-p/1409190#M83654

[Hemanshu Sood]

Thanks @Nic Brough -Adaptavist- @Alexey Matveev @Joe Pitt @Payne
i find the Script Runner solution very intriguing. However, i forgot to mention that I am using Jira 6.4.13 and this version does not support SR 5.4.38.

Any alternatives?

[Nic Brough -Adaptavist-]

Get an older version of Script Runner, one that is valid for 6.4 (the UPM under "find new add-ons" should automatically do this for you - it will install the latest compatible version of any add-on, and provide an "upload" link if you can't connect your Jira to the internet)