How to stop an existing Issue Type from being used

[Peter Norris]

We have a particular issue type that has been in use for a number of years, but now we've decided to stop using it, in favour of out-of-the-box functionality.

What's the best way to stop users from raising new tickets of this type?

My immediate response was to remove that issue type from the Issue Type Schemes it resides in, but I'm told that would stop people from looking up existing records (which we want to be able to do).

Thoughts?

Pete.

[Gaurav.Gupta · Accepted solution]

Hi Peter, 

I was able to hide the Issue type with ScriptRunner Behaviour script.  The following script would hide the Issue type in Issue creation screen. 

const issueTypeField = getFieldById("issuetype");

const allowedIssueTypeIds = ['XXXXX']; // ID for issue type you want to restrict

issueTypeField.setOptionsVisibility(allowedIssueTypeIds, false);

In my script above, instead of true, I’m using false as the isVisible parameter to hide the specified option. 
You can read more on this in ScriptRunner documentation : I hope this helps.

Kindly give it a try and let me know if this works 

Regards

Gaurav 

[Peter Norris]

This works great, thanks @Gaurav Gupta 

[Gary Spross]

Like others have said, the only option is to "move" the existing issues to another issue type, then you can delete the issue type you don't want from the issue type scheme associated with the project.

You could use a validator, however I wasn't a fan of this option because the issue type still appears in the list in the Create dialog. So a user can select it, fill out all the data fields, then, when they click submit, they are informed that they aren't permitted to create an issue of this type.

There's also the option of add-on's (such as ScriptRunner) that provide an ability to "disable" issue types from appearing in the select list. However, I've found issues with this method because it can depend on how the screen loads and how quickly a user selects an issue type from the list. Here's an example of a ScriptRunner script that restricts the creation of an issue type based on a users group/role: https://community.atlassian.com/t5/Jira-questions/Re-How-to-set-permission-on-issues-creation-by-issue-type/qaq-p/1094254/comment-id/348835#M348835.

Atlassian should implement a "disabled" ability for issue types within an issue type scheme. This would allow existing issues of that type to "live on", but restrict the ability of selecting that issue type for future issue creation.

Here are a few other community posts asking similar questions:

• https://community.atlassian.com/t5/Jira-questions/Disable-an-issue-type-and-keep-issue-with-the-disabled-issue/qaq-p/727477
• https://community.atlassian.com/t5/Jira-Service-Management/Disable-Remove-issue-type/qaq-p/1180042

[Mathew Lederman]

The validator is still the best native option in my opinion.

If you remove all the fields in the issue type create screen the validator is effective. Also, you can use a Message field (for Edit) to display a message before creation.

[Peter Norris]

Thanks, Gary - we've tried the ScriptRunner solution as proposed by you and Gaurav Gupta and that seems to work for us. Thanks so much for your reply!

[Yvonne Sutter]

I would not use a validator like some of the others, I would keep the workflow lean, move all issues of the old issue type to the new one with a bulk edit (if necessary, use something to differentiate these issues to the other ones of the new type, e.g. set a label to all these issues or use a custom field or whatever) and then remove the old issue type.

Just make sure to think of all dependencies like workflows, automations etc. the old issue type might have.

[Michiel Schuijer]

This. I prefer that method as well, much cleaner, no surprises/questions in the future, etc.

[Saili]

Hi @Peter Norris ,

You can move the issues from one issue type(the issue type you want to remove) to other issue type by using option 'Move' and then remove the issue type to want to get rid of.

Then the data you want would remain...

Let me know if this works

[Malie Lalor]

You have a few options. As others have suggested, you can migrate existing issues to an issue type that you want to retain, before removing the issue type from the issue type scheme. What I've done in the past is to add a label with the issue type name so that I'd be able to pull a list of them later if needed. You can choose to retain all the custom field information (even if the issue type you migrate to doesn't have all the same fields, the info would still be there and you can pull it out with a JQL search if you need to). 

You could try this with a small set of issues first if you're not very confident with bulk moving. 

Or, if you do want to retain the issue type but make it impossible to create issues of that type, then I would suggest combining the suggestions already given with adding a message on the create screen for the deprecated issue type. 

• Create a custom field of the "Message" type where you can add guidance for your users in "Details"
• Make this a mandatory field in that issue type's Create screen
• You can make your message look pretty - search for Atlassian Text Formatting Notation Help - something like {panel:bgColor=#FFFFCE} This issue type is no longer being used. Please create an XYZ issue instead.{panel}

Hope that helps!

[korada Venkatesh]

Create an empty group
add a validator at the create transition that users must be part of that empty group to create tickets for that issuetype, this will prevent any user from creating a new issue, 

if you have add-on's like script runner you can create a behavior to hide that issuetype.

[Jim D]

I would recommend a bulk edit on the old issue types and change them all to an issue type that you'll continue using for new tickets, then delete the old issue type.

The only warning is any fields particular to the old issue type won't be visible in the new issue type but will still be in the DB.

[jeff_kehler]

My first thought when I read this was to create a validator to restrict creation to one specific user (myself) and no one else. 

[Keimpe de Jong]

And I would add a text in the name of the issue to inform users about the EOL of the issuetype. This off course on top of the regular internal communication channels.

[Angie Affolter]

What about only offering a view screen (so that they can see old issues) and taking all the fields off the edit screen and create screens? I've not tried it, but sounds like an easy thing if it works 

[Alfonso Leiva]

Hi Peter,

Even though it sounds like a good idea, depending on the size of your instance, it could be a time-demanding task.

The top of the iceberg is changing the issue type schemes, replacing the old for a new one, and/or moving existing issues to the new issue type.

What you may not be seeing is everything else that is linked to issue types

• Workflow Schemes
• Issue Type Screen Schemes
• Field Configuration Schemes
• Custom Field contexts

And even further, you could have Automation rules and specific workflow conditions, validations and post-functions related to issue types. And it could go even beyond, if you are using scripting-type apps.

I would say there is no easy way to pull this in a short time frame, but with dedication, coordination and communication with all the teams and areas using the issue type you would like to stop using, you can get to do it.

[Robert Condon]

I'd probably add a validator to the create step of the workflow.

Best practice is probably a user permission validator, but some could slip through.

You could instead make any number of impossible conditions:

• Required field that is not on the create issue screen
• Previous state required