Sync statuses between two issues in Jira Server without Automation Pro

Slava Gefen

Hi dear Community!

As you know we can't more use Automation Pro in Server (The App wasn't purchased before).

Description of the Task:
In our Server we have two different issuetypes in different projects. They always have a link between each other. And imagine they have two identical statuses with All transition:

IN PROGRESS <-- All
PENDING QA <-- All

I need when any of these issutypes is going to In Progress or Pending QA to move linked issuetype to the same status. And we need to be aware of the loop that can happen.

I can do it with Automation Pro for 5 minutes!, but we can't use it. In Automation Lite version there isn't Branch Rule option to move linked issue.

What is the best and easiest option to cover this requirement?

Thanks in advance
With kind regards
Slava

Radek Dostál

If you have Jira Suite Utilities installed (JSU), then it has a workflow post-function called 'Linked Transition (JSU)' which you can configure by issue links or by jql.

I believe that Jira Misc Workflow Extensions (JMWE) has something similar, although we don't have that plugin so not totally sure, but I think I saw it to have something like that.

In general, workflow sounds like one approach you could take.

 

If not from the workflow, you would need something akin to a listener - such ScriptRunner's listeners, which can be built and set up to listen to issue events in the projects, and once the status has been changed, it can then trigger a transition on linked issues. Automation for Jira works in a similar way so functionally it's not too different.

Wouldn't go down this road though unless it is the last resort, since it adds up to maintenance and code execution as the listeners need to process events to evaluate whether they should do something or not. Small, asynchronous, probably too microscopic to care about, but it's still an extra execution, whereas workflows would trigger only when actually necessary. More of a principle I guess, the maintenance is the worse part since this would require a groovy script which you would need to keep up to date with API (if it does change in the future).