Set and clear resolution code

[Patrik Hoglund]

Hi, Im working with a workflow that contains multiple green statuses and all transitions. Currently with no resolution set nor cleared. Started up with setting resolution to 

Closed	Resolution is done
Resolved	Resolution is fixed
Rejected	Resolution is Wont do

Issue is that when going from Rejected to Closed, resolution wont do doesn't change to done. Do I need to add another post function to clear resolution?

[John Funk · Accepted solution]

Hi Patrik,

Wow, there is a lot going on there. Yes, you can add a post function to clear the resolution and put that as the first step. Then add another post function to set the resolution and have it lower down in the steps. But the problem is that there is no guarantee that Jira will execute the steps in that order. 

I think you would be better off having a single Done status with a transition screen with the Resolution field on the screen where the user sets the Resolution when it is moved to Done. 

If you don't trust your users, you could a self looping transition to the Done status with a condition that only the Jira Administrators group could execute that would clear the resolution. Then other one with the same condition that would include the transition screen so you could set it to the right one. 

[John Funk]

Yes, you could do that through an Automation rule. Also, please reply inline with my answer so readers can follow the conversation better.  :-)

[Patrik Hoglund]

What If I merely copy the workflow, edit the inactive copy by removing the three green, adding the new green done incl resolution screen. Back to the project with scheme and associate with adjusted workflow to the affected issue type. Here I assume there will be a migration path where I need to take some mapping decisions..? and then follow through?

Could this be a way do you think?

[Jack Brickey]

Here would be my suggestion.

1. setup the proper Resolution values (rejected, resolved)
2. add a screen to the transition to Done requiring selection of Resolution 
3. using JQL, query the issues in Rejected and bulk edit setting the Resolution to Rejected.
4. using JQL, query the issues with Resolution of Rejected and bulk edit transitioning them to Done.
5. Repeat 3 & 4 for Resolved (but see my $0.02 below on Resolved)
6. edit your workflow to remove obsolete statuses

$0.02 on Resolved: if your workflow is such that issues often transition to resolved prior to going to closed then I would keep the resolved status separate. I would not set the resolution on resolved, unless it was a terminal status like Done.

[John Funk]

Yes, Jack's suggestion is the route to go because you need to get the Resolutions all set in the single status before removing the other ones. The migration process probably won't allow you to set the Resolution field at the same time.

[Patrik Hoglund]

@Jack Brickey and @John Funk really helpful guidance. I need to get back a draw a step by step schedule so I bring all the bits and pieces together. Will come back if more questions appear or even better tell you once done.

[Jack Brickey]

You can create some test issues in various statuses to test your process if desired. But not as complicated as it may sound.

[Jack Brickey]

Yes you would need to set when entering any of the three done category statuses and you would need to add a clear field for each "all" transition into each of the other (non-done) statuses except Open. As an aside, you might consider eliminating the rejected status and using the Resolution field to indicate rejected.

[Patrik Hoglund]

Hi John, thanks for swift response! Question If I choose to set up one single Done status and apply a resolution screen, covering Rejected, wont do etc. What happens when I remove the existing green statuses Closed, Resolved and Rejected? Is there a need of applying some sort of mapping up front so I dont affect tickets irrespectively where they are in the WF?