Conditions

Conditions control who can perform a transition and the circumstances under which they can perform this transition. If any part of a transition's condition fails, the user will not see the transition link on the 'view issue' page.

You can use JJupin and SIL to define a large set of conditions beside Jira's built-in conditions, by just adding a (k) SIL Condition to the transition and publishing the workflow, as described here.

Below are just a few common examples:

Previous status

A workflow condition that allows you to disable a particular transition if the current issue has never been in a specific status:

number STATUS_RESOLVED = 5;
string[] status_history = fieldHistory(key, "status");

return elementExists(status_history, STATUS_RESOLVED);

You can also check if the current issue was not in a specific status just before it entered the current status:

number STATUS_OPEN = 1;
string[] status_history = fieldHistory(key, "status");
string previous_status = getElement(status_history, size(status_history)-3);

return previous_status == STATUS_OPEN;

Cascading select comparer

A workflow condition that allows you to disable a particular transition when two cascading selects are equals:

Let's suppose the cascading select custom fields are named `CASCADING 1` and `CASCADING 2` and their custom fields ids are `customfield_10000` and `customfield_10001`:

//Condition Cascading select comparer

if(length(#{CASCADING 1}) == 0 && length(#{CASCADING 2}) == 0) { //both cascading select are empty
   return true;
}
if(#{CASCADING 1} == #{CASCADING 2}) {
   return true;
}
return false;

Equivalent to:

//Condition Cascading select comparer

if(length(customfield_10000) == 0 && length(customfield_10001) == 0) { //both cascading select are empty
   return true;
}
if(customfield_10000 == customfield_10001) {
   return true;
}
return false;

Condition based on regular expression

A workflow condition that allows you to disable a particular transition when a custom field value doesn't match to a regular expression:

For instance, let's create a custom field select, named `Combo`, with the following options: `accepted.1234567890.text-123`, `accepted.0987654321.othertext-123456` and `notaccepted-456`.

The transition will be present for the workflow if the value of the custom field will match to the regular regular expression for values like `accepted.1234567890.text-123` or `accepted.0987654321.othertext-123456`. Value `notaccepted-456` doesn't match to the regular expression, so the transition will not be present when the custom field has this value.

The expressions matching to the custom field value have the following form: string "accepted." followed by exactly 10 numbers, then it is followed by ".", then the expression is followed by a alpha text only. The following character is "-" and finally it has some numbers.

//Condition based on regular expression

return matches(Combo, "accepted(.)(\\\\d+\\\\.?){10}(.)[a-z]+(-)(\\\\d+\\\\.?)"));

Condition based on linked issues

A workflow condition that allows you to disable a particular transition when the current issue has no linked issues:

//Condition on linked issues

if(isNull(getLinkedIssues(key)) || size(linkedIssues(key))==0) {
   return false;
}

Condition on non-linked issue

A workflow condition that allows you to disable a particular transition when the current issue has linked issues.

It's the reverse condition of the SIL code above:

//Condition on non-linked issue

if(isNull(getLinkedIssues(key)) || size(linkedIssues(key))==0) {
   return true;
}
return false;

Condition based on mathematical expression

A workflow condition that allows you to disable a particular transition when the mathematical expression calculated does not accomplish the script condition:

//Condition based on mathematical expression

number n = rand() + e();
return n >= 1;

To be more specific, rand() generates a number in interval [0, 1] and e() is the Euler constant. The workflow condition will be not available if the sum of the random number and the Euler constant is less than 1.

More details can be found on Math Routines section.

Condition based on date-time expression

A SIL condition which checks if due date is before current date:

return dueDate > currentDate();

More useful date routines can be found in the Date Routines section.

Except assignee Condition

A workflow condition that allows you to disable a particular transition when the current logged in user is not the issue assignee user.

//Except assignee condition

return currentUser() == assignee;

Except reporter condition

A workflow condition that allows you to disable a particular transition when the current logged in user is not the issue reporter user.

//Except reporter condition

return currentUser() == reporter;

Condition based on boolean expression

Control if a transition can be executed if the logged work time is less than the estimated time.

return timeSpent <= originalEstimate;

Condition based on String equality

Decide if a transition should be disabled using string equality.

return currentUser() == "admin";

Use currentUser() to get the current logged in user.

Condition based on date comparison 

Use created and updated to compare 2 dates.

return created < updated;

To get the currentDate, you can use currentDate() routine.

Condition based on comparison of numeric fields

Create 2 custom fields of type numeric and compare them in a condition.

return customfield_11300 < customfield_11301;

Where customfield_11300 and customfield_11301 are JIRA custom fields of type numeric.

Condition based on equality of time spans

Define 3 intervals and compare them in a condition.

interval tstSpent = "1d 4h";
interval tstEstimate = "1w";
interval tstRemaining = "3d 4h";

return tstEstimate == (tstSpent + tstRemaining);

In the example above it is used the addition between tstSpent and tstRemaining, but the user can also use the subtraction between tstEstimate and any of the other 2 intervals.