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?
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.
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.
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.
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs