Clone wiki

JIRA Workflow Toolbox / amazing / Make Linked Issues and Subtasks Progress through its Workflows

./img/moved.png

Make Linked Issues, Subtasks or JQL selected issues Progress through its Workflows

JIRA Workflow Toolbox provides features for making issues automatically progress through the workflow. Issues that can be transitioned this way are:

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 (subtaks, 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 "Condition on linked issues", "Validation on linked issues", "Condition on subtasks", "Validation on subtasks", "Condition based on JQL query", "Validation based on JQL query", "Boolean condition with math, date-time or text-string terms and "Boolean validation 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

  • 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.

Usage 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:

  1. 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".
  2. 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.

1) 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":

1. Validator "Validation on linked issues":

./amazing/make-other-issues-progress/validation-on-linked-issue-1.png
./amazing/make-other-issues-progress/validation-on-linked-issue-2.png
./amazing/make-other-issues-progress/validation-on-linked-issue-3.png
./amazing/make-other-issues-progress/validation-on-linked-issue-4.png

Once configured, transition "Start Progress" will look like this:
./amazing/make-other-issues-progress/start-progress-configuration.png


2. Validator "Boolean validator with math, date-time or text-string terms" with the following configuration:

./amazing/make-other-issues-progress/boolean-validation-1.png

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:
./amazing/make-other-issues-progress/boolean-validation-final-configuration.png

2) Configuration of transitions "Done", "Resolve Issue" and "Close Issue"

Use post-function "Write field on linked issues or subtasks" 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:

./amazing/make-other-issues-progress/write-linked-issues-1.png
./amazing/make-other-issues-progress/write-linked-issues-2.png
./amazing/make-other-issues-progress/write-linked-issues-3.png

NOTE: Due to Issue #248, 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 se prevent the transition execution whenever the validation is not satisfied.

Once configured, transition transitions "Resolve Issue", "Close Issue" and "Done" will look like this:

./amazing/make-other-issues-progress/resolve-issue-configuration.png

Other examples of making issues progress through its workflow

Updated