Features used to implement the example

• Copy parsed text to a field

A sub-task can execute a post-function in order to move its parent issue through the workflow. For example, we can close a parent issue when all sub-tasks are closed.

How to make parent issue progress through its workflow?

A sub-task can make its parent issue transition using 2 different sets of virtual fields:

• "Parent's issue status" and "Parent's issue status (delayed writing)": if we write the name of a status (e.g., Open, In Progress, Closed, ...) into any of these 2 virtual fields, the plugin will look for transitions in parent's workflow going from parent's current status to a status with the same name as the one we have written. If a suitable transition is found and its conditions and validations are satisfied, the transition will be executed, and parent issue will be moved to entered status.

• "Execute transition on parent issue" and "Execute transition on parent issue (delayed execution)": if we write the name of a transition (e.g., Start Progress, Close Issue, ...) into any of these 2 virtual fields, the plugin will look for a transition in parent's workflow departing from parent's current status with the entered name. If that transition exists and its conditions and validations are satisfied, the transition will be executed.

In order to transition parent issue, a sub-task typically uses post-function Copy parsed text to a field with the following configuration:

• Target field: any of the 4 virtual fields above described.
• Parsing mode: basic
• Text to be parsed...: the name of a status or the name of a transition, depending of the selected target field.

Also Set a field as a function of other fields can be used.

Difference between "Parent's issue status" and "Parent's issue status (delayed writing)" or "Execute transition on parent issue" and "Execute transition on parent issue (delayed execution)"

Virtual fields "Parent's issue status" and "Execute transition on parent issue" try to transition parent issue as soon as they are written, while fields "Execute transition on parent issue (delayed execution)" and "Execute transition on parent issue (delayed execution)" wait for sub-task's current transition to end execution, before transitioning parent issue.

When a sub-task uses "Execute transition on parent issue (delayed execution)" or "Execute transition on parent issue (delayed execution)" fields for transitioning its parent issue, parent's execution attempt won't be carried out until current sub-task's transition has finished, and thus sub-task is in the new status. For this reason, these fields are used when parent issue is blocked by a condition or validator depending on sub-tasks statuses, typically by a conditions or validators like "Sub-Task Blocking Condition", Condition and validation on sub-tasks and Boolean condition and validator with math. date-time or text-string terms, etc. 

Example: Reopen parent issue when a sub-task is reopened

In this example we show how to automatically reopen an issue in status "Done" when any of its sub-tasks is reopened. Let's assume the following workflow:

We will insert post-function Copy parsed text to a field into transitions "Reopen" and "Reopen and start progress" with the following configuration: 

Note that:

• %{00042} is field code for Parent's issue status
• We haven't written the name of the statuses in upper case, but like In Progress and Done, because Jira UI typically shows the name of statuses in upper case, while the actual names are not. You can check up the actual names at Jira Administration screens

Once configured, transitions "Reopen" and "Reopen and start progress" will look like this: