From the area of tips and tricks for Jira, but already for advanced administrators and users, this post is about transition properties or workflow properties. Such special properties can be set, for example, for one or more transitions (status transitions), but also for statuses of a workflow. Part 1 will deal with transition properties, part 2 will look at status properties.
A transition property can be used to change the order of workflow buttons or to offer only certain values for resolutons in the transition – individualizations that would otherwise only be possible with additional apps for Jira. Other properties can be set, but are rarely used in practice. If Jira Service Management is used, additional entries may appear that one has not actively set oneself – if a transition has also been set as visible in the Service Portal, to name just one example.
The workflow properties can be stored when editing a workflow. Here, you simply have to click on “Properties” for a transition or a status (where you also find post functions, etc.). In the following, the property keys with the corresponding values can be entered.
Limiting resolutions with transition properties
Resolutions in Jira are usually stored globally and cannot be limited per project or, better, per task type, even though this is a long-awaited feature-request by the community. Therefore, it is often controlled via a validator that only certain solutions can be selected. If it is particularly important to you that only certain solutions are displayed, you can alternatively store the solutions only for certain status transitions. This is especially suitable if separate workflows are configured for Jira projects anyway.
jira.field.resolution.includejira.field.resolution.exclude
The two properties shown above can be stored for this case. As the name implies, they can be used to remove individual resolutions from a selection or to display only certain ones.
When defining the properties, only the IDs of the solutions can be used, not their names. To get the IDs of the solutions, you can for example look at the end of the current URL when editing them. Here the ID of the current solution is listed, for example, with “?id=10041”.
Attention: The stored transition property only influences the selection in a screen mask (Transition Screen) stored for the transition. This means on the one hand that a screen with the corresponding field (resolution) must also be set up and defined and on the other hand that, for example, other resolutions can still be overwritten in the field by a post function.
Honcion recommends using the “include” variant. This way, not all affected workflows have to be modified, should new resolutions be created. Furthermore, it is often easier to decide which solutions are valid instead of listing all invalid ones.
What actually decides in which order the buttons from the workflow are displayed? In truth, this is a question that customers ask us more often than we would like to. The answer is simple: in the order in which they were originally created in the workflow – not alphabetically.
If you are bothered by this, you can influence the order.
opsbar-sequenceA positive number can be specified as the value. Before Jira 9 was released, this meant that the transition with the smallest value would be listed on the far left. Since Jira 9 and in Jira Cloud, this means that the transition is listed first – so in case of doubt, it is the one that is the only one displayed before you expand the other transitions or statuses.
Honicon recommends specifying the opsbar sequence in increments of 10, for example. This way it is easier to add more transitions later if necessary and it is not necessary to adjust all transitions again.