Why are issues never Resolved when using Greenhopper Simplified Workflow

[Jack Baty]

I love the concept of the Greenhopper Simplified Workflow, and have transitioned several projects to that workflow. What I've discovered is that Issues are never Resolved (meaning Resolution is never set to Resolved, even though the status does.)

This is confusing when looking at issues in other contexts, as they still appear in users' dashboards, etc. What is the best way to cause issues in the "Done" column to have their Resolutions set during the transition?

[Michael Tokar · Accepted solution]

The effect of converting to a Simplified Workflow for an existing project, with regards to Resolution, is intentional.

When creating a new project with a Simplified Workflow, it is easy to dictate which status of the workflow equates to the "Done" column - it's the Done status. So we set up the workflow in this instance to set the Resolution to "Done" when issues are transitioned into that status, and for all other transitions we unset the Resolution.

When converting existing projects to a Simplified Workflow, we did not do the work to either automatically determine or manually ask the user what the "Done" column status(es) should be - this was deemed as further work. But at the same time, we had to remove all existing transitions from their current workflow in order to simplify it (so that the new workflow only contains global transitions). And we also wanted to remove all screens from all transitions.

So we were left with a question of what to do about with the Resolution field. We decided that we would unset it on any transition, because in (n-1) cases (where n is the number of columns), that was the desired effect (i.e. that an issue becomes unresolved). This was important because we did not want to invalidate JIRA's logic around unresolved issues (certain JQL and gadgets look at this value, for example).

So out of the box, the Resolution field will not be set correctly. But the upshot is, the customer can configure the simplified workflow to re-instate the behaviour that they require for their workflow. Either they can put a screen on the global transition(s) for status(es) in the Done column of their board, or they can change their post functions to set the Resolution accordingly.

[Jack Baty]

This all makes sense, thank you for the detailed follow up. I have been, as you suggested, editing the post function after converting to the simplified workflow. It's not too much trouble.

[Deleted user]

https://confluence.atlassian.com/display/GHKB/Unable+to+set+issues+to+Resolved+using+Greenhopper+Simplified+Workflow

[Jobin Kuruvilla [Adaptavist]]

Check the workflow and see if the resolution is set the post function. This has to be set on the workflow.

[Jack Baty]

The Resolution is explicitly cleared in that workflow step. Converting the workflow to the Simplified Workflow for an existing project seems to do that. It might turn out that I have to modify the workflow after conversion each time, but would rather not. Just making sure this is intended behavior.

Incidentally, the project's original workflow *did* set Resolution correclty.

[Jobin Kuruvilla [Adaptavist]]

That is the reason why it is not shows as resolved. You will have to modify the workflow to set it back, not clear it.

[Jack Baty]

That's what I've done, thanks. Seems like a surprise behavior (and one that probably shouldn't be necessary) for anyone converting an existing workflow to the Simplified Greenhopper Workflow.

[Svein Are Grønsund]

The whole point, I guess, is that using "Simplified Workflow" is just too simple...
The "GreenHopper Simplified Workflow"-workflow tells us: "Do not manually modify this workflow".

So, that's a big bummer for GHSW...

[Robert Schweser]

The simple transitions for "Resolve" and "Close" do not set resolution via post function correctly. They rather clear resolution which is not wished behaviour. Wished behaviour would be to set the resolution to a default value.