A problem I’ve noticed with the workflows people create (not my own ones of course!) is that the resolution is often inconsistent.
This might stem from a lack of understanding of the resolution field and what it’s used for. In the default workflow, there is a state called Resolved, and when you get to that state the resolution must be set, and if you reopen the issue it’s unset, so people tend to think it happens by magic. It doesn’t, that’s the way the default workflow has been written, and there is no relationship between workflow states and the resolution, unless you define one.
The common mistake is to allow a transition to a “closed” state, such as Closed or Rejected that does not have the resolution on the transition screen, or set it in a post-function. Most of jira’s canned queries such as “My assigned issues” and so on filter on resolution being null, so the problem then is that these issues that are in a “closed” state remain in people’s “stacks“.
A more insidious sitation arises when you have a transition from a resolved state to an unresolved one, for example Reopen. If you forget to add a post-function to set the resolution to None, the issue can be in the Open state, however doesn’t appear in anyone’s list of unresolved issues, meaning it’s quite likely to get forgotten.
The resolution field is a blunt instrument that I don’t particularly like, but you don’t really have much choice but to use it. I don’t like it because one man’s resolution is not everyone’s, if I’m a developer I consider it resolved when I’m code complete, however for the QA engineer it’s not resolved until tested, for the build-meister not until released, for the end-user it’s not resolved until they’ve got the updated software and confirmed the bug is fixed.
So, the new version of this plugin attempts to show you where a state can be inconsistent, that is, where by one route or another, you can get to a state where the resolution may be either set or unset. I can’t think of a scenario where this kind of workflow has a valid use case – if you can, let me know. Here’s the simplest example of a problem:
The black dot on the end of the Resolve action indicates that the resolution is set on this transition. On Reopen it is not unset, so the Open state is coloured red – issues in this state could be other resolved or unresolved. That’s bad.
Fix it by setting a post-function to unset the resolution:
Notice the white dot at the end of Reopen.
Here’s a more “real-world” example:
Someone has forgetten to unset the resolution on the “Return to Open” action. The “ambiguity” leaches through to the other states, so issues in any of the red states can be either resolved or unresolved.
This version will, optionally, show you the name of any transition view (screen), if there is one:
Also, if you are using SVG (and I strongly recommend you do) you can click through on the step names and actions and you’ll be taken to the relevant workflow screens. Handy for fixing up any broken workflows.
A minor improvement is that it will now show all workflows for any given project, so the fact that the report is accessible through the Browse Projects screen now actually makes sense.