Have you ever needed a button in an issue just to do stuff without modifying the issue status? And what about applying edit permissions on the field level? This article shows how to set workflows for covering both needs in a cost-effective way.
Natively, Jira workflows count with a really powerful feature which is just a little bit hidden. Let's name it global looping transition, which is the key functionality for achieving our goals, and has definitely changed the way I design workflows since I discovered it.
What is a global looping transition?
A global looping transition is a special kind of workflow transition that meets these two characteristics at once:
- It is global, meaning that it can be used from any status in the workflow.
- It loops, meaning that the status of origin is also the status of destination. In other words, the status of an issue does not change on using this kind of transition.
How does it look like?
This is the graphical representation of a global looping transition named Do something:
Nice! Isn't it?
How can I set that kind of transition?
A global looping transition can only be set through the diagram mode of the workflow editor, by following these steps:
- Click on the Add transition button:
- Select the following values in the dialog form:
- Give the transition a descriptive name and, finally, click on the Add button.
That's it! The transition will be created.
Some notes about global looping transitions...
- You'll need to refresh the workflow editor page in your web browser before being able to add conditions, validators, post-functions or transition properties.
- A workflow may contain multiple global looping transitions, all of which will be displayed in the same area.
- (Edit note on 17/Dec/2021: This point now just applies to Data Center instances) Adding opsbar-sequence property to all workflow transitions is a good way for displaying transitions in the desired order. While that's true for any kind of transitions, it's especially relevant for global looping ones, as it's generally preferable to display first those transitions that lead to a status change for advancing the issue through its workflow.
Use case: Triggering a post-function
Sometimes you just need to add a button to the issue detail view in order to perform actions somehow related to said issue which do not require to apply a status change.
The inefficient multiple looping (not global) transitions approach
While that purpose may be covered by creating a transition from a status to itself and adding an appropriate post-function, a similar transition should be created in each status from which the functionality should be available.
This approach is not easy to maintain, as it requires setting multiple times the very same thing, both in its initial configuration and in future changes.
The inconsistent global (not looping) transition approach
An alternative yet bad approach consists of adding a post-function to a global transition targeting a status specifically created for this purpose. In example, if the post-function executes a calculation and modifies a field accordingly, a status named Calculating with a global transition could be created.
However, this is just a poor workaround, because:
- Calculating is not a phase (status) in the issue's lifecycle (workflow), but a mere action that requires less than a second to complete. Furthermore, it can affect your reporting measures of time in status or even SLA compliance, unless additional configurations were set to prevent such things from happening.
- Workflows with strict requirements which rely on issues following certain specific paths may force to set additional means for returning the issue to the previous status in order to preserve consistency. Applying those extra settings would unnecessarily increase complexity with no value in return. What is more, I've even witnessed a case where a post-function was set to transition automatically to the previous status and, on stumbling upon an error caused by a different post-function, an infinite transition loop was caused. Definitely not worth it!
The correct global looping transition approach
As you've probably already noticed, using a global looping transition with the appropriate post-function is the correct way to go here, as it doesn't have any of the disadvantages caused by its counterparties.
This is a simple and clean solution that complies with both the DRY and KISS principles (dry kiss?), strongly recommended in Jira configurations.
Use case: Edit permission on the field level
The ability to control who can edit a specific field in Jira is usually implemented this way:
- Remove the field from the edit issue screen.
- Add the field to a new screen.
- Add the new screen to a wokflow transition.
- Add a condition to the transition to enable it just for the appropriate users.
However, doing so without the help of a global looping transition counts with the same disadvantages previously shown in the section Use case: Triggering a post-function.
Thanks to the native global looping transition feature, controlling edit permission on the field level is both an easier and a more feasible task.
