Modify or create a new workflow.
Add a new condition.
Most of the built-in workflow functions can be customized with Condition code or Additional actions code, so if you can use a built-in script, you should.
Example 1. Where to put your scripts?
For each type of workflow function, the plugin will provide the current
transientVars in the script binding. That means you can refer to them using these variables, without declaring them.
If you use Intellij IDEA, you can add a dynamic property for these variables of the correct type. Alternatively you can just redeclare it with type information:
import com.atlassian.jira.issue.Issue; Issue issue = issue
Condition functions define whether an action is visible and available for a particular issue. Jira runs condition functions more often than you would expect, so avoid doing any long processing in them.
Set the variable
false depending on whether you want the action to be permitted or not. Note that
passesCondition defaults to true, so if it is unset in your script, then the action will be permitted.
Avoid complex scripts with heavy processing requirements, as the condition is evaluated by Jira several times if it is applicable instead of once.
Instead of a custom condition you may prefer to use Simple Scripted Condition, where you can just return
Technical Stuff for Advanced Users
The conditions are mini groovy scripts. When they are modified, they are automatically compiled and cached.
The following variables are available:
Table of custom field names (not IDs) to their values for this issue, used for quickly looking up CF values
User doing the transition, name is available as
Used for getting attachments
Current issue in this transition
Used for checking links
Could be used if the cfValues is not sufficient, or you need to check values on other issues
In validators, a copy of this issue before the user changed it in this transition. So for instance, to ensure the assignee was changed during a transition, in your validation condition you might put:
Base URL of Jira, used for building URL links
Many of the built-in functions have a condition option, as it’s not possible in Jira to only activate a workflow post-function if some other condition is true. You can test conditions before setting them up for real on the Condition Tester admin script. If there is a syntax error it will be shown.
Let’s say you want to check the resolution is Won’t Fix. You could write
issue.resolution.name == "Won't Fix"
However, if the resolution is not set at all, ie is null, this code would produce an error:
Therefore it should be written with the safe-navigation operator, ie:
issue.resolution?.name == "Won't Fix"
Note the question mark.
Power assertions are a very useful debugging tool. On the questionable line you are having problems with, simply begin it with
As an example, let’s say I am trying to check the value for a custom field called MySelect, which has two values Yes and No. I want my workflow function to happen only if the value is set to Yes. As a naive first step, I try
cfValues['MySelect'] == "Yes", this doesn’t work for an issue where it should, so I add the
assert cfValues['MySelect'] == "Yes"
which gives the following failure:
Note this is a bit counter-intuitive, as apparently both sides are "Yes", yet the
== was false. Whenever you see something odd like this check the type of class:
assert cfValues['MySelect'].class == String.class | | | Yes | false class com.atlassian.jira.issue.customfields.option.LazyLoadedOption
This tells us that value for this custom field key is actually a LazyLoadedOption, and we should call the getValue() method. It just so happens that the toString() method of Option returns the value, but you can’t compare them as strings.
Similarly, a multiselect is stored as a List of Options, so the correct code to use to check to see if a particular value is present is:
That is, use the spread-dot operator to call the getValue() method on every item, then we check if "AAA" is in that list.
In short, if you are having problems use the Condition Tester built-in script and add assert statements.
Remove the assert before using as a real condition - the assertion doesn’t return anything as such so your condition will always evaluate to false if you leave the assert in.