Assign issue to a user based on some conditional logic

[Rudd]

We have a handful of projects all using the same workflow. As an issue transitions from our Verified step to Built step, we would like to populate the Assignee field with the person who is the lead tester for that project. Is there a way to do this in the common workflow? On that transition, we would want something like:

if project == foo then assignee=bob

elsif project == bar then assignee=fred

etc....

[Nic Brough -Adaptavist- · Accepted solution]

I tend to agree with Bob on this one, having a separate workflow for each project is a nightmare to be avoided whereever you can. Similar projects should use the same schemes and share as much configuration as possible.

In this case, I'd go with at least line 1 on this list, combined with some of the others:

• No, I'm not willing to create and maintain hundreds of slightly different workflows and have to edit them every time a person moves
• Bob's original answer - "use the script runner".
• Write my own post-function.
• Use "Pro fields" plugin to provide a space to name "lead tester" and use that in a post function
• Set up a role like "tester" and then use "assign to role"

Note that you probably need a combination to avoid hard coding a list of users against a project - that's a nightmare to maintain as well - it's far better to use a role

[Sm Tahsin]

Hi Rudd,

Using the same workflow across all the projects is definetely not a good practice. Please create different workflows as well as workflow schemes which will make your life much easier.

There are numbers of post fucntions avialable for workflow transition through which you can handle a reasonable numbers of automated tasks for tansitions. Please have a look into that admin sections.

Hope this will help.

Thanks

[Bob Swift]

I totally disagree with this answer. Having a standard workflow across multiple projects is a good practice if it works for your situation. Obviously, sometimes multiple workflows are needed. But having a unique workflow per project is a big administration burden.

[Sm Tahsin]

Thanks Bob. I said "Same" not the "Standard". :)

[Nic Brough -Adaptavist-]

I'm not sure it matters whether its a standard workflow, I tend to agree with Bob - it's not a good practice to use multiple different workflows across multiple projects. It IS good practice to use the same workflow for all projects that work in similar ways.

[Nic Brough -Adaptavist-]

No, it went paid a couple of versions ago. You could use the old version, but it won't work on Jira 7

[Tammy Robinson]

Is Script runner still free? I only see a trial download for free. Trying to confirm if this is the same? https://marketplace.atlassian.com/plugins/com.onresolve.jira.groovy.groovyrunner/server/overview

[Eric Herr]

I am attempting to solve the same problem. We have multiple projects that use the same workflow. The issue is when we are trasnitioniing from "In Progress" to "QA". We have three different QA tracks depending on Which product/project is being tested. I would like the transitioni from "In Progress" to "QA" to have a conditional transition that assignes the story to the appropriate QA person/team depending on which project the story is associated with.

Story EOS-1055 assignee = Bill

Story GCW-253 assignee = Liz

[Amanda Wimpy]

Rudd,

We came across the same problem, in general the workflows were the same other than a couple of transitions. We found the easiest way was to create a separate transition between the two statuses (in your example Verify to Built) for each project. Then you can add a condition using the Script condition option. Select 'Allow transition if query matches a JQL query' and the enter the query "project = [your project]"

[Stephan Bielmann]

Bob his answer is the way to go if you want one single transition in your workflow. Using JSU you would need to have as many transitions in your step, as there are projects. Each one having a condition verifying the project key, and if matching, only that transition would be shown, and each of these transitions would have its own post function to set the correct assignee.

[Bob Swift]

Your specific case is pretty simple, so there are a number of alternatives. Script runner is free and the script it pretty straightforward in this case and can be handled as a single post function looks similar to your logic above.

Update issues (paid) post function could also be used. However, you would need a post function for each possible assignee. Configuration in this case would be:

Condition value: %project%, condition pattern: (FOO)|(GOO)|(HOO)

Issue entries to update: %original_key%

Assignee field: Specific value, value: bob

There is a more advanced configuration possible using a cascade select field configuration to capture the mapping of projects to names that could reduce this to a single post function, but, only worth adding the complexity if you had a large number of mappings.