Features used to implement the example
- Write field on linked issues or sub-tasks
- Update issue fields
- Block or hide a transition for an issue depending on its issue links
- Boolean Validator with math, date-time or text-string terms
Jira Workflow Toolbox provides features for making issues automatically progress through the workflow. Issues that can be transitioned this way are:
- Using post-function Write field on linked issues or sub-tasks
- Linked issues
- Subtasks
- Using post-function Update issue fields
- Issues returned by a JQL query
- Issues returned by a Issue List expression
Making issues progress through its workflow using a post-function
An issue can transition other issues progress through its workflow by executing a post-function for writing the name of target status (e.g., "Open", "In Progress", "Closed", ...) into virtual fields "Issue status" or "Issue status (delayed writing)", or the name of a transition into virtual fields "Execute transition" and "Execute transition (delayed execution)" on other issues.
Care must be taken to write the name of the status or transition exactly as it is. Since version 6.x, Jira shows almost always the status name in upper case. To check the real name of the status, try to edit it at Administration > Issues > Statuses > Edit
. Since version 2.1.20, JIRA Workflow Toolbox is case insensitive for issue status, so you can write the name of the status as you see it in UI.
Writing into virtual field "Issue status"
When the name of a status (e.g., "Open", "In Progress", "Closed", ...) is written into virtual field "Issue status" on another issue, that issue will progress through its workflow to that status, whenever there is a transition from current status to the new one, and conditions and validators in that transition are currently satisfied. Post-functions in that transition will also be executed, the same way they are when transition is triggered manually.
Obviously, if there isn't a transition from current status to target status in the workflow of the issue we want to move, it will remain in its current status.
Why is needed another virtual field: "Issue status (delayed writing)"?
"Issue status (delayed writing)" works like virtual field "Issue status", with the only difference that effective status change is carried out after transition execution in current issue (i.e., the issue executing the post-function) has been completed. On the other hand, when writing into "Issue status", status change is done immediately (i.e. within transition). This delayed way of writing is very useful when the issue you want to make progress through its workflow (sub-tasks, linked issues or JQL selected issues) is blocked by the status of current issue. The cause for this blockage might be a condition or a validator that depends on current issue's status, like Block or hide a transition for an issue depending on its issue links, Condition and validation on sub-tasks, Condition and validation based on JQL query and Boolean condition and validator with math. date-time or text-string terms.
Virtual fields "Execute transition" and "Execute transition (delayed execution)"
Since version 2.1.20, there are two additional virtual fields for transitioning issues: "Execute transition" and "Execute transition (delayed execution)". These fields behave similarly to "Issue status" and "Issue status (delayed writing)" respectively, with the only difference that they expect the name of a transition, instead of the name of a status.
These new fields are particularly useful if you have global transitions in your workflow, or if you have more than one transition available for going to target status. With them you specify which transition you want to be executed.
Hiding a transition to interactive Jira users
Sometimes we add transitions to the workflow, intended to be triggered exclusively by post-functions. In these cases we hide the transition to interactive (human) Jira users using condition "Transition is triggered by Jira Workflow Toolbox post-function".
Features used for transitioning issues
- Post-function Write field on linked issues or sub-tasks or Update issue fields, used to write into virtual fields "Issue status" or "Issue status (delayed writing)" the name of the target status we want to move issues to, or into virtual fields "Execute transition" or "Execute transition (delayed execution)" the name of the transition we want to execute.
- Virtual fields "Issue status" or "Issue status (delayed writing)": when the name of a status is written into any of these fields, the plugin tries to executed any transition available from current issue status to the written status. Conditions and validations in the transition should be satisfied. These fields are selected in parameter Target field of post-function.
- Virtual fields "Execute transition" or "Execute transition (delayed execution)": when the name of a transition is written into any of these fields, the plugin tries to executed a transition with the given name from current issue status. Conditions and validations in the transition should be satisfied. These fields are selected in parameter Target field of post-function.
Example: Automatically move issues to "In Progress" status once all its blocker issues are moved to "Closed", "Resolved" or "Done" statuses
In this example we edit 2 transitions in our workflows:
- Transition "Start Progress": we add a validation into transition "Start Progress" in order to prevent its execution whenever there are blocking issues in statuses different from "Done", "Resolved" and "Closed".
- Transitions "Done", "Resolve Issue" and "Close Issue": we add a post-function for to moving blocked issues to "In Progress" status. The validator added previously in "Start Progress" transition will prevent the execution of this transition while there still are blocking issues not yet closed or resolved.
These 2 transitions might be in the same workflow, or belong to different workflows.
Configuration of transition "Start Progress"
You can use any of these 2 validators in transition "Start progress" to block its execution until all blocking issues are in statuses "Resolved", "Closed" or "Done":
Validator Block or hide a transition for an issue depending on its issue links:
Once configured, transition "Start Progress" will look like this:
Validator Boolean Validator with math, date-time or text-string terms with the following configuration:
Boolean validation: count(linkedIssues("is blocked by")) = count(filterByStatus(linkedIssues("is blocked by"), "Resolved, Closed, Done"))
Once configured, transition "Start Progress" will look like this:
Configuration of transitions "Done", "Resolve Issue" and "Close Issue"
Use post-function Write field on linked issues or sub-tasks to write the name of the transition we want to execute into field "Issue status (delayed writing)" of blocked issue. We use a boolean expresion in order to check whether the rest of blocking issues are already resolved or closed, and only when this boolean expression is satisfied the writing operation is actually done:
If you are using Jira 7.0 or higher with versions of Jira Workflow Toolbox older than 2.2.8, you should input the following boolean expression in parameter Filtering by field values:
count(filterByStatus(linkedIssues("is blocked by"), "Closed, Resolved, Done")) = count(linkedIssues("is blocked by")) - 1
This way it prevents the transition execution whenever the validation is not satisfied.
Once configured, transition transitions "Resolve Issue", "Close Issue" and "Done" will look like this:
Other examples of that functions
Write field on linked issues or sub-tasks
- Add and remove a single or a set of items from multi valued fields
- Automatically become watcher of every issue blocking an issue assigned to you
- Automatically close resolved sub-tasks when parent issue is closed
- Automatically resolve an epic when all its stories are resolved
- Compose dynamic text by inserting field values in a text template
- Copy "Due date" into a date type custom field in a linked issue if it's greater than current issue's "Due date"
- Copy attachments from one issue to another
- Create a comment in sub-tasks when parent transitions
- Creating a Jira Service Desk internal comment
- Creating a Jira Service Desk internal comment on linked issues
- Execute transition in epic
- Make linked issues, sub-tasks and JQL selected issues progress through its workflows
- Moving sub-tasks to "Open" status when parent issue moves to "In Progress"
- Sum sub-task's "Time Spent" (work logs) and add it to a certain linked issue
- Transition sub-tasks when parent is transitioned
- Add and remove a single or a set of items from multi valued fields
- Compose dynamic text by inserting field values in a text template
- Creating a Jira Service Desk internal comment
- Creating a Jira Service Desk internal comment on linked issues
- Make linked issues, sub-tasks and JQL selected issues progress through its workflows
- Moving sub-tasks to "Open" status when parent issue moves to "In Progress"
- Parse Email adresses to watchers list
- Set priority for issues that have been in a certain status for longer than 24 hours
- Transition linked issues in currently active sprint
- Transition only a sub-task among several ones
- Using project properties to calculate custom sequence numbers
- Writing a comment to blocked issues when blocking issues are resolved
Block or hide a transition for an issue depending on its issue links
- Automatically resolve an epic when all its stories are resolved
- Make linked issues, sub-tasks and JQL selected issues progress through its workflows
Boolean Validator with math, date-time or text-string terms
- Block a transition until all sub-tasks have certains fields populated
- Block an epic's transition depending on linked issues status and due date
- Block or hide a transition for an issue depending on its issue links
- Block or unblock a transition after an issue rested a specific time in a status
- Block transition until all sub-tasks are in a specific status category
- Close parent issue when all sub-tasks are closed
- Enforce a field (Select List) to be set when another field (Radio Button) has a certain value (works with any kind of field type)
- Ensure that all issues linked with a certain issue link type have "Due Date" field set
- If field A is populated then, field B must also be populated
- Limit issue creation per role and issue type
- Limit the number of hours a user can log per day
- Limit valid dates for work logs
- Make "Time Spent" field required when there is no time logged in the issue
- Make a custom field mandatory when priority is "Critical" or "Blocker" and issue type is "Incident"
- Make attachment mandatory depending on the value of certain custom field
- Make different fields mandatory depending on the value of a Select List custom field
- Make linked issues, sub-tasks and JQL selected issues progress through its workflows
- Make parent issue progress through its workflow
- Prevent issue creation if another issue with same field value already exists
- Reject duplicated file names in attachments
- Require at least one sub-task in status "Resolved" or "Closed" when "Testing required" is selected in Check-Box custom field
- Require issue link when resolving as duplicate
- Restrict parent issue from closing if it has sub-tasks that were created during a given parent issue status
- Restrict sub-task type creation depending on parent issue status
- Restrict sub-task type creation depending on parent issue type
- Set a condition in a global transition which only applies in a certain status
- Validate a custom field "Story Points" has been given a value in Fibonacci sequence
- Validate compatible values selection among dependent custom fields
- Validate only issue links created in transition screen
- Validate that multi-user picker custom field A does not contain any user in multi-user picker custom field B
- Validation and condition based on time expressions
- Validation based on the value of a date type project property
- Validation on issue attachments
- Validation on MIME types of issue attachments
- Validation on sibling sub-tasks depending on issue type and status
- Validation on the value of a Cascading Select field