nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Reopened JIRA stats

Richard Jones7

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

Accepted answers

Joe Pitt

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.

All comments

unknown

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.

Joe Pitt

Richard Jones7

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?

Tuncay Senturk _Snapbytes_

Hi Richard,

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

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

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 Jones7

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!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-administration

jira-core

workflow