Moving pictures apparently being all the rage now, I was going to do one of these so-called “movies” myself to demonstrate automatic workflow transitions, but, they’re FOOKING HARD! Fiddling around with key frames and splicing clips and so on, and then listening to my voice droning back at me, I couldn’t take it. I can’t inflict that on my 3 subscribers (hello kids). I will chuck it in at the end but with no voiceover.
Today’s topic is how to auto-transition an issue through a workflow action if some condition is true, which allows us to have multiple starting states for a workflow. Does it? Well, yes, if the Create Issue function has a post-function that switches on some condition and then actions the issue, putting it in the effective “start state”. For example, take the contrived example below, where we want have different start states depending on the issue Priority:
The post-function on Create Issue will move all issues to one of the states below, depending on whether the issue is Critical, Trivial, or anything else. As users are not aware of the AutoTriage state, and there are no possible transitions back to it, you have effectively different starting states.
To do this you need three post-functions on Create Issue, one for each possible following action. The conditions respectively are:
issue.getPriorityObject.name == 'Critical' // to Critical Start issue.getPriorityObject.name == 'Trivial' // to Trivial Start ! ['Critical','Trivial'].contains(issue.getPriorityObject.name) // Any other priority to Other Start
Note that the conditions of the workflow functions should be mutually exclusive as in the above example.
As of a recent release of the script runner plugin, it’s also possible to use the Fasttrack function as a listener… which is fine, but it’s probably best to keep the workflow logic all in the same place, ie the workflow.
Here’s another use case. We have a jira project that the customers can enter issues in to. The “bugs” the customers report are mostly a result of their misuse of our brilliant product, and as such we want our project manager guy to reject them, or at least get more information from the user, before they even come on to our radar. However if we, the developers, enter a bug in the project we know it’s a proper bug, probably because we caused it, and we want it to come straight in to our todo list.
In other words, it’s the standard workflow, with a new status tacked on at the beginning where we weed out the cruft.
So to make this work, as in the example above, we add as the final post-function on create issue the fast-track function to action through the Validate action, so it looks like this:
There are a number of sample conditions here, clicking them will copy the relevant code to the text box. Flick through them to understand what they do and how they work. There is already a sample function that checks if the current user is a member of the Administrators role for the project to which the issue relates, so we can just click that and change the text to Developers.
Finally we need to select the action that will be applied, ie Validate. If there is more than one Validate action listed make sure the ID is the right one.
Right, here’s the video. I’m showing how to do exactly the same thing but with a listener, (Admin -> Script Listeners). With a listener, in addition to the above, you select the issue events and projects to fire on. As I said though, by preference do this with a workflow, because if you then apply the workflow to another project you get the same behaviour. I also demonstrate that it actually work with a user in the developer role, then use the admin built-in script to switch to a user in the Users role, and show that issues they create end up in Awaiting Validation.