Best approach for recategorizing historical issues

[Kevin Kamel]

I manage several queues on behalf of my employer, in total we have about 12,000 issues tracked through JIRA.

As our organization has grown, we have found that some of our initial categories for tickets no longer accurately describe the work being tracked.

For example, graphic design. Rather than our design department working independently of our development team, they now work with us on a near daily basis. They went from illustrating to adding the resulting image to the product to modifying stylesheets, etc. This probably is a common refrain seen here, as this type of involvement is far more common with today's agile teams.

In our case, we have atomic tagging. A ticket is either "code" or "graphic design". Our idea was to move all the "graphic design" into "code", which would make categorizing tickets more straightforward and consistent. Unfortunately updating tickets like this modifies the "updated" and "resolved" dates, which are critical fields we use for searching on.

How have the rest of you dealt with this type of problem? Do you avoid recategorizing entirely? If so, how do you grow out your queues over time? or perhaps there is even a way to avoid updating "updated" and "resolved" which by itself might get me closer to a solution.

My example above is actually a simple one for our organization. We have a category called "legwork" which was pretty much for miscellaneous operational tasks. This queue has both "code" and "graphic design" in it, so we need to manually iterate over those to fix that up. Fortunately there aren't too many issues within this particular queue.

[GabrielleJ]

How do you tag issues? Updating the values will definitely affect the "updated" date and the only scenario I am thinking of that the "resolved" dates will be modified is because of your workflow restrictions that CLOSED issues cannot edited. Is this true?

• If you badly need this 2 dates to be in tact, I may suggest creating separate custom fields for these "old issues" namely "Original Updated Date" and "Original Resolve Date", bulk update these values then do your thing. You may just hide this on the screen by not adding it in the "View Screen".
• Sacrifice "Updated Date" and modify your worflow so that you can "Edit" close issues. This will not affect the "Resolve Date" because you do not need to open them.
• If you are really desperate, go directly in the database which I am highly against.

[Kevin Kamel]

Hi Gabrielle, Thanks for responding. We migrated over from trac many years ago, so in some ways our use of the system still mirrors that tool. We "tag" by just assigning a single category to a ticket. Basically our categories are a list of roles and projects right now, for example "graphic design" and "feature X". This doesn't make much sense of course, which is why I posted this question, so I can get this fixed. I... did not know that the queue could allow tickets to be edited once they are closed. If that's an allowed option (I'm going to immediately read the docs), then this is going to at least partly help solve my problem. To date we have been opening and closing tickets in order to make edits to them. Based on your options, I think option 2 makes the most sense. Is this what you do within your own projects?

[GabrielleJ]

Yes, I have done this with one of my projects before (one of my JIRA instance has 1,200 Projects and is sharing a single template so after I put the "editable close issue", i quickly reverted it back after I need my needed changes).