Reopened JIRA stats

[Richard Jones]

Hi All

im trying to figure out some reopened JIRA stats. Consider I have the awful scenario below

JIRA assigned to user1. Fixed on 1 Jan

JIRA reopened by QA on 2 Jan. JIRA still assigned to user1

JIRA assigned to user1. Fixed on 3 Jan

JIRA reopened by QA on 4 Jan. JIRA still assigned to user1

JIRA assigned to user2. Fixed on 5 Jan

JIRA closed by QA on 6 Jan. 

This JIRA has been reopened twice but the end state is with user2 so it looks like they are the user who is responsible for the reopenings. I lose the fact that user1 is there.

I have a custom workflow in my project and want to know if I can put this information somewhere when the JIRA is reopened. I asked on a separate post about adding the current user (or text) somewhere to a custom field but Im wondering if this is the best idea. Has anyone got any other ideas?

Thanks

[Joe Pitt · Accepted solution]

I discourage reopening and usually only allow the project lead to do it. Too often it is done because someone is too lazy to create a new ticket. I work on the premise a ticket should only be reopened if it was closed and the issue isn't really fixed or completed. I also set a flag, 'Reopened', to yes in the reopen transition so all reopened tickets will be easy to find. Storing past info in another field becomes problematic if you allow reopening multiple times. It looks like your problem is the fix isn't passing QA. I suggest you put a QA step in the workflow BEFORE closing the ticket and put in a transition back to development if it doesn't pass QA.

[Richard Jones]

Hi Joe, thanks for reply. "I also set a flag, 'Reopened', to yes in the reopen transition s" this is interesting and could be a better solution. How were you able to do this? Via the workflow transitions?

[Joe Pitt]

Yes. I have a select list of Yes, No with a default of No. It only appears on the view screen and is set to Yes with a post function in the reopen transition. I also have a required select field with common reasons like, Wrong issue closed, Customer unsatisfied, etc. And another required text field for Reopen details. Only users in the administrator role can reopen tickets. One site I worked required a CR to request a ticket be reopened. In other words they made it easier to do the job right the first time than ask for it to be reopened.

[Richard Jones]

Thanks Joe, I think this is a great idea and will apply this. Ive looked at the post function but only have a limited number of field to choose from. There are not any custom fields in the selection. Am I missing something? Thanks for your help!

[Joe Pitt]

I always install the jira-suite-utilities plugin and it allows you to use custom fields.

[Richard Jones]

great addon thanks!

[Tuncay Senturk]

Hi Richard,

Have you checked Enhancer Plugin for JIRA's reopening counter, reopening history tab panel solutions?

http://jiraenhancerplugin.com/documentation.html#reopeningcounter

[Deleted user]

If so, just open a new ticket (a clone ticket or linked ticket) so the original ticket will have preserved information, this is what I've done with some of my projects, "Reopening" the ticket will open a new clone ticket since we don't want to lose vital information (like original close date, resolved date, SLA metrics, assignee etc...). This is a case to case basis though.