nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Best way to avoid duplicate workflows?

kevinbushman

Hi, I'd like to set up a groovy script or something similar to avoid having two workflows that do the same thing except one presents one set of resolution fields versus the other.

In a nutshell, I'd like to create a separate list of resolution options depending upon the issue type without having to manage two very similar workflows.

I am able to accomplish this today with the pain of the two similar workflows:

image2017-3-8 11:47:0.png

Can this be done with a groovy script instead?

image2017-3-8 11:47:0.png

image2017-3-16 12:31:19.png

Accepted answers

Phill Fox

Hi Kevin Bushman

You can achieve what you want very easily with the standard JIRA workflow functionality. No need to write groovy script or anything. The key aspect you need to know is the property on resolution during a transition. Full details of the available properties are here https://confluence.atlassian.com/adminjiraserver071/workflow-properties-802592825.html

So to solve your problem you have two transition routes (one for each set of issue types which would be defined in the condition) to closure each of which has the property

jira.field.resolution.include

set with the appropriate list of IDs for the resolutions you wish to be available.

One thing to watch out for is if you add a new resolution at any point in the future you will need to add it to the workflow property as well.

All comments

Phill Fox

Hi Kevin Bushman

So to solve your problem you have two transition routes (one for each set of issue types which would be defined in the condition) to closure each of which has the property

jira.field.resolution.include

set with the appropriate list of IDs for the resolutions you wish to be available.

One thing to watch out for is if you add a new resolution at any point in the future you will need to add it to the workflow property as well.

kevinbushman

Nice! This sounds like exactly what I am looking for. But I'm trying to understand what you mean.

My current implementation the is using property

jira.field.resolution.include

however I am confused on what you mean by having two transition routes. I could add two transitions but I'm not clear on how to map those to specific issue types.

Edit: To add to my solution, this page solved my problem but causing me to have to maintain two nearly identical workflows. https://answers.atlassian.com/questions/144864

Phill Fox

@Kevin Bushman

Here is an example of two routes between statuses which are available for different conditions.

image2017-3-16 12:31:19.png

Here I have two different transitions to Done from In Progress one which would offer the resolutions associated with the work being completed and the second which would be used for a cancelled request. On the cancelled request we can use a post-function to update the resolution to Cancelled automatically. Whereas on the Completed we can offer the subset of resolutions in the transition screen to allow the user to select.

Now to extend this model and only allow certain issuetypes to see a specific transition we use the Condition on the transition and for this you need to use a plugin such as Adaptavist Scriptrunner for JIRA to identify those issues of a certain issuetype.

So in Scriptrunner you would use the scripted condition

<a href="http://issue.issueTypeObject.name" rel="nofollow noopener noreferrer">issue.issueTypeObject.name</a> == "New Feature"

You would replace the reference to "New Feature" with the name of the issuetype you want to use the transition for.

kevinbushman

Got it! This is exactly what I needed. Thank you. Unfortunately, it makes my workflows look a little more messy but It's not a big deal. (We have many routes to Resolution)

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud

workflow