Linked Transition Post Function
This is the JSU for Jira Cloud documentation. If you are using JSU on Jira Server or on Jira Data Center, see our JSU Server/Data Center documentation.
On this page: |
Description
The ‘Linked Transition’ post function triggers a transition on a related issue. It can be very powerful, especially when used with the Create a Linked Issue post function to connect the workflows of two issues. You can also specify any number of fields to be copied to the related issue.
Want to try a new way of creating this post function?
We’re working to make it even easier for you to build workflow rules with JSU. A simplied version of this post function is now available in our Universal Rule Builder – a new editor experience currently in beta.
Configuration
You must specify the workflow and transition that you want to apply to the related issue.
Precondition
Issue relation
Choose the type of issue that you want to transition to the new status.
Related issues are identified by one of the following Jira concepts:
Issue link: You can define the link type to define which issues will be modified by the operation. If the post function includes the link type is ANY option, the operation will be performed on any linked issues.
Parent / Sub-Task: The related issue is either a parent or a subtask of the issue.
Epic / Issue in Epic: The other issue is either an epic related by an epic link, or it is part of an epic. This is only applicable if you have Jira Software installed.
JQL: A JQL query will be executed to retrieve the issues that the post function will modify. You can use some placeholders in the JQL query, which will be replaced with the current field values of the issue in transition. For tips on writing the JQL query, see JQL Reference or our JQL Use Cases for some examples.
Transition
When the post function is performed, it will trigger the transition with that particular ID on the linked issues. When the post function is executed, it will appear as if the transition ID is available on the target issue, no matter what workflow and transition name you picked in the configuration screen (that is only to make it easier to find a particular transition ID during configuration).
If the transition with that ID is not available on the linked issue (probably because it is in a different status) nothing will happen. Also, no comments or fields are copied, and no resolution is set.
It is important to keep this in mind and design your workflows accordingly to prevent them from becoming 'out of sync'. You might also use several 'Linked Transition' post functions in the same transition, each calling a different target transition to match different possible statuses of the linked issue.
Be aware that there might be some workflow conditions or validators, which could prevent a transition from being performed.
The transition on the linked issue will be performed as the user defined by the Peform As User option.
Conditional statuses
Use this option if you want the issue to be transitioned only when ALL of the sibling issues are in a specified status. Only 'the last' issue will trigger a linked transition.
Consider a test case issue that has several linked bugs. The bugs are linked as 'from test' to the test case. Only when the last bug is fixed, the test case should be set to the Status 'Ready for Re-Test'.
This prevents this transition from being executed when the first bug is fixed.
Optional settings
Resolution
To set the resolution, you need a resolution field on the transition screen. For more information, see Atlassian’s Mapping a Screen to a Workflow Transition page.
If any transition screen contains the resolution field, that field becomes mandatory. Here you have a chance to set a value for the resolution to be able to perform that transition.
Resolution in the post function configuration | Resolution on the issues at the start when the transition is performed | What happens? |
|---|---|---|
Empty | (does not matter) | The resolution on the issue will not change. |
Any value | Any other value | The resolution will be set to the defined value. |
Perform As User
Copy fields
These fields will be copied to the linked issue after the transition occurs. The conditions and validators of your linked transition will still use the old field values.
Supported field types
Troubleshooting
If a linked transition does not get triggered or even blocks your origin transition, these are a few things to check:
Did you check the log files? There are cases when the linked transition is not performed silently. But you will find a message in the log files on the server. You might increase to logging level (as described in Linked Transition).
What happens when you manually click the linked transition? Does it work, or might there be a problem?
Does this problem only happen to other users? Check that the user performing the origin transition has enough permissions for the linked transition.
Is there a transition screen for the linked transition? Is there a condition, validator, or post function on the linked transition? Could these prevent the transition from being performed in an automatized way (with the 'Linked Transition' post function)?
In the order of all post functions of the origin transition, the 'Linked Transition' post function must be the last one.
Did you try to set a particular Resolution in the linked transition? Or with 'Resolution=empty' - does it then work?
Infinite Loop Detection
An infinite loop can occur when executing the Linked Transition post function. An infinite loop results in an endless cycle of issue creation and follow-up transitions following the triggering of the origin issue. When a loop is detected JSU will stop the execution and log an execution failure.
When using post functions that create issues or follow-up transitions, consider the outcome of the rule and the user permissions of your project teams. You can also use preconditions to restrict when rules are run to reduce the likelihood of causing an infinite loop. Learn more about how JSU identifies an infinite loop in Infinite Loop Detection.