Can you just delete issue types...?

[Laura Gerlev Hansen]

We're cleaning our Jira instance and one of the things we want to do is delete issue types.

We've had a lot of admins over the time and they've done what they felt like, so we have sooo many issue types that doesn't make sense. E.g. we have 15 sub-tasks and many issues with almost the same name.

I know how to delete the issue types, but what concerns me is what it does to our history/data. E.g. if a project has used issue types to distinguish between different products/tools instead of components, EPIC's or something else, we might ruin the history by removing their issue types and just converting their issues to "tasks".

I'd like some input on the things you've done and considered. Have you e.g. removed the issue type "bug subtask" and then added that as a component on the new issue? Just to be sure that some historic information is kept? Or did you just clean up without doing anything to save old information?

We're of course only looking into deleting issue types that are not currently being used, so it's only projects that are "archived" we're affecting.

[Nic Brough -Adaptavist- · Accepted solution]

Absolutely all of what @Joe Pitt said.  Especially on change control - you really should do that, and a Jira project is a brilliant way to do it.

On the specifics of deleting an issue type, yes, you can "just" delete it.  BUT, do not.  There are impacts you need to think about.

First, the good things you should know:

• Jira won't let you delete directly.  It will start asking you about what you want to migrate.  If you've got any number of "thingy" issues, in one project or many, it's going to ask you what issue type to replace it with, and then it's going to migrate them
• The deletion will not be directly recorded itself, but all the changes made to issues while migrating them will be.  Albeit as simple text, it'll still be recorded in the issue history.

Now the bits to worry about:

Fields can have contexts that tie them to issue types.   For example, maybe a field called "Impact" only exists for "Risk" issue types.  If you delete the issue type Risk and migrate all your risks to "story" which does not have the impact field, there is nowhere for that field to store any existing data - it will be permanently deleted (the issue history will say "impact went from X to empty")

People may have configured filters, boards, enmails, JSD portals, dashboards and even system things like workflow post-functions, scripts, triggers that look at issue type.  If you delete an issue type, these will stop working if they were using that type in a structured way.  

So, in short, yes you could delete, but you really should check usage and talk to your users about the impacts before you do.

(By the way, by "structured", I mean that your specific issue type is used directly.  Imagine a report that counts issues grouped by issue type, based on a filter of "project = xyz".  That's not using your issue type directly, the report will work fine if you delete one.  But if the filter were "project = xyz and issuetype in (bug, feature, thing)" and you delete thing, that filter will start to fail because thing is no longer a valid object)

[Laura Gerlev Hansen]

Thank you, @Nic Brough -Adaptavist- . Seems that we should go another way than just deleting issue types.

[Joe Pitt · Accepted solution]

If the issue type has data in it I don't believe you can delete it. I suggest you drop the issue type from the issue type scheme and stop using them. If you delete anything the history data associated with it will also be deleted. 

Going forward, to avoid this type of issue I suggest you put JIRA under change control

 I STRONGLY suggest you treat JIRA like a production system, put it under change control (CR), and track all requests for any updates, especially new projects, new custom fields, changes in any of the schemes, etc. That way at least the reporter will know when the actions happen and you'll have a audit trail. I've worked many similar tools to JIRA and too many times no one knows anything about why they are configured why they are because there is no requirements or CR. Things are just done based on emails that have disappeared and hallway or lunch conversations.  

If you don't already have a separate change control tool create a JIRA project. I use a basic workflow with a few custom issue types:

Custom field: with a select list of create, update. The description would be to create a new field or modify a current select list, buttons, etc. of a current one

Create Project: I would have text fields for issue types, custom fields, select list/values, per issue types

New Issue Type: description would include all fields and workflow desired.

Workflow: Select list of Create, update, delete. Description of what needed.

Other: Select list of Notification Scheme, permission scheme, field configuration, other

This should get you started. If you aren't familiar with your CR process there should be a configuration management person to talk to.

The goal is to manage what you do and be able to track who asked for what. For instance, if someone wants a new custom field you want to check to see if there already is one you can use that they don't know about. JIRA

[Laura Gerlev Hansen]

Thank you for the great inputs, @Joe Pitt