Disable/Remove issue type

[Michelle Greenfield]

Hi - how do I go about removing an issue type? There are a number of issues attached to it as well.

[Nic Brough -Adaptavist-]

You can delete them from Admin -> Issues -> Issue types.  Or just remove them from a project in the project settings.

However, if you remove an issue type, you will need to migrate existing issues using it over to another type.  (Jira will walk you through the migration though)

[Rebecca McMahon]

Hi @Nic Brough -Adaptavist- 

It's been a few years since your response on this however I have a related question:

We are currently performing some work after migrating to Cloud and are only looking to move working/open tickets to the new Bugs project. These tickets were previously a ticket type in a older/migrated project. We would like a way to remove the ticket type from being able to be selected but retain the type for the closed Bug tickets remaining in the project. 

Is there any way this might be possible?

Thank you

[Nic Brough -Adaptavist-]

No, if you remove an issue type from a project, you have to migrate the existing issues to a valid type.  You can't set a configuration to point to something that isn't there.

Somewhere, there's a request for "ability to archive an issue type in a project (preventing create and move-to)", but I'm afraid it's not one I've got bookmarked, and I don't know if it's open or Atlassian have "won't fix" resolved it.

[Rebecca McMahon]

Hi @Nic Brough -Adaptavist- 

Thank you for the quick response. I looked around some other posts and found this suggestion that I will test.

I am not looking to completely remove the type but just disable it from being selected as a type when creating a new ticket while retaining the type for the older tickets that are remaining in the project.

[Nic Brough -Adaptavist-]

Hi,

Joe's suggestion isn't any different.  His first sentence is correct - if you have issues of that type in the project, you won't be able to delete the issue type from the scheme unless you migrate all the existing issues to another type.  

[Emanuel Y]

Hi @Rebecca McMahon,

I know it has been awhile since your post. I just came across this will looking to solve another issue. I just wanted to provide a workaround. If the goal is to prevent users from being able to create a specific type of Jira issue. You could add a condition to your workflow, locking down the ability to create the type your thinking about. However, you may have to tie those issues to another workflow.

If the goal is to visibly remove the issue type... as noted by @Nic Brough -Adaptavist-  you will have to migrate all the existing issues to another type. 

[Barry Scallan]

Another option I've implemented today

Use case: Keep the issue type but essentially make it redundant in your workflow for later reference to tickets associated with that Type.  My case is where I've resolved all tickets of that type and moved them to a Completed status. The problem faced is people can still open tickets of this type which I do not want. So rather than delete the type keep it in place and inform users that it is no longer used

The workflow change I've implemented is to enable if a user creates a redundant ticket type and move it straight to Complete with a message stating the ticket type is no longer used and to contact person X about your ticket. 

Works for my case so sharing in case it's something useful for others. 

[davesoft11]

Just want to lend my support to @Rebecca McMahon who is asking for a way to effectively "grandfather" an issue type (not delete it, @Joe Pitt / @Nic Brough -Adaptavist- ).

This is also what I need, and I'm guessing the feature is not available. I have thousands of closed jira of that Issue Type, and there is no way to "migrate" them without making up details about the type of issue that they really were.

I get it: the GUI is obviously tied to a relational database with foreign keys enforcing data integrity. But this is an old software problem to solve: you simply add a "Grandfathered" column to the IssueTypes table. So you don't have to delete them; you just flag them. And the GUI for new Issues respects the Grandfathered flag (and doesn't present those as options), but everywhere else (queries, etc), the old issue type is there. It's history; you can't erase it.

I may use the suggestion about putting in a workflow validation in. Of course, to be useful, it would have to act immediately, preventing the issue from being created at all. I'll have to experiment to see if that's possible (unless one of you knows?).

Either way, this is an annoying solution, since I have a bunch of workflows, and I will have to add it to all of them.

[Nic Brough -Adaptavist-]

Yep, I'm 100% with you on the ability to "archive" (or grandfather) an issue type in a scheme (can't create new issues of that type, but don't have to migrate existing ones - is the short description of how I would do it)

Jira does it for options in some of the select-list type fields and I'd like to see it for issue types, and hence I don't think "put a flag on issue types in a scheme that you don't want to let people create any more", is that hard.

It is actually something very close to what I did for a client a while ago - I amended the code for the "create issue" process, so that it ignored some of their issue types.  It was a very simple "fix", 5 lines of code that stopped their dead issue types being offered, selected by name, and it was global, not based on issue type and project. just "if issue type = X, don't offer it during create" in every project, but I am sure it would not be much harder to do it by issue type scheme.

There's a bit more complexity on removing config that hangs off the issue type, but I'd say that should be pushed on to admins, and kept simple.  "You can't delete this scheme because you have an (archived) issue type set to use it" is consistent with the rest.

But, yes, TLDR, for the current state, go for the validator.

[davesoft11]

Thanks. I think we're on the same page :-) 

[davesoft11]

Just following up that I used a solution generally based on what Emanuel Y proposed above to solve this. 

1. Create a new workflow called "Short Circuit" with one state, "OPEN".
2. Double click the transition to OPEN and add a Validator.
3. The only Validator options I have is Permissions. Select an obscure permission that no one needs on your team. I chose "Delete All Worklogs" because we are not currently using Worklogs in this project. Save the workflow.
4. Go to the Workflow Scheme and assign the grandfathered Issue Type to this new workflow "Short Circuit". 
   1. When you do this, the wizard will force you to map all the States from the old workflow to a State in your new "Short Circuit" workflow. 
   2. In order to not lose information about the actual state of those jira, note the list of States that need support, and go edit the "Short Circuit" workflow and add those States to that workflow. They will be free floating; not connected by any transitions.
   3. Cancel and restart the Workflow Scheme change above, and the wizard will no longer complain about the need to map States, and it will move all those issues to the new workflow.
5. Go to your Permission Scheme and deny everyone's rights to "Delete All Worklogs" or whatever permission you chose.
6. Go try to create a new jira with that grandfathered Issue Type. You will get an error message in red at the top: "User 'XXX' doesn't have the 'Delete All Worklogs' permission". This message is cryptic; I'd really like it to say that the requested Issue Type has been grandfathered and to use something else, but I don't know how to do that (tips??). But, it gets the job done because the user is prevented from ever creating the issue.

Hope this helps.

[Inti]

Thanks, @davesoft11, for taking the time to present in detail the workaround using a Short Circuit workflow. I like it, I haven't tried it, but it seems so well-thought-out that I am confident that's the right way to go.  

[Melissa Evans]

I would also love for this to be an option to archive old issue types, yet retain the data from those requests previously using that issue type. The above solve is a bit difficult for me to follow—is there a simpler way?