Simple Scripted Condition

Use the Simple scripted condition to run a simple embedded script that determines whether an issue should be permitted to transition to a particular status within a workflow. This built-in condition allows you to write a Groovy script that can evaluate a wide range of conditions based on issue fields, workflow states, project properties, user permissions, and other contextual data.

This built-in condition is particularly useful for teams with unique process requirements that need to enforce specific criteria for issue lifecycle management.

Use this condition

Go to Administration > Issues > Workflows.
Select Edit on the workflow you want to add a condition to.
Select the transition to which you wish to add a condition.
Under Options, select Conditions.
On the Transition page, select Add condition.
Select Simple scripted condition [ScriptRunner].
Select Add.
Optional: Enter a note that describes the condition. This allows you to identify your workflow condition more easily.
Enter a condition of your choice or enter one of the example scripts displayed further down this page:

If the script returns true, the transition is allowed. If it returns false the user will not be allowed to perform the transition.
Optional: Enter an issue key to preview if the result evaluates true or false.
Select Update.
Select Publish and choose if you want to save a backup copy of the workflow.

You can now test to see if this workflow condition works.

Examples

Each of the examples below is based on specific workflows. Make sure you adjust the examples appropriately to suit your own workflow/s.

Examine the issue history and separate duties

Sometimes you want different people from the same group or role to execute different steps of the workflow. For example, you have a bug validation workflow and you do not want the person that resolved an the issue to validate the fix.

You can put the following code as a condition on the Validate transition, which will prevent the user that transitioned the issue to the Resolved status from validation:

groovy
import com.atlassian.jira.component.ComponentAccessor
 
def changeHistoryManager = ComponentAccessor.getChangeHistoryManager()
def currentUserKey = ComponentAccessor.getJiraAuthenticationContext().getLoggedInUser()?.key
 
// returns true if there are no transitions to the target state by the current user
!changeHistoryManager.getAllChangeItems(issue).find {
    it.field == "status" &&
        currentUserKey == it.userKey &&
        "Resolved" in it.toValues.values()
}

Check all sub-tasks are assigned to the current user

You can use a condition to check that all sub-tasks are assigned to the current user before the parent task can be transitioned:

groovy
// Retrieve the current logged in user using a different variable name
def loggedInUser = Users.getLoggedInUser()

// Retrieve all sub-tasks of the current issue
def subTasks = issue.getSubTaskObjects()

// Check if all sub-tasks are assigned to the logged in user
def allAssignedToLoggedInUser = subTasks.every { subTask ->
    subTask.assignee?.username == loggedInUser.username
}

// Return true if all sub-tasks are assigned to the logged in user, false otherwise
return allAssignedToLoggedInUser

Check all QA sub-tasks are resolved

This example is described in more detail on the Conditions Tutorial page.

You can use a condition to check that all QA sub-tasks are resolved before the parent issue can be transitioned:

groovy
def subTasks = issue.getSubTaskObjects()
  
return !subTasks.any {
    it.issueType.name == "QA" && !it.resolution
}

Check all linked issues are resolved