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

[Slava Gefen · Accepted solution]

I've also resolved this by using of JWT Automation that is quite similar to Automation Pro.

[Radek Dostál · Accepted solution]

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).

[Slava Gefen]

Hi @Radek Dostál ,

Thanks for such a detailed answer!

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

 I need to check, but the question:
 Won't it cause the loop when the issues will be transitioning in the same status without end?

With regards
Slava

[David Fischer]

With JMWE, you'll be able to use "Conditional Execution" to prevent the post function from running if the current issue is already in the destination status. This will prevent any infinite loop.

[Radek Dostál]

That's a fair point, didn't occur to me if it could cause a loop, it certainly might.

[Slava Gefen]

@Radek Dostál I've set it with JSU, as you advised 👍 Also I added precondition to check linked issue status before transition: if it's already in required status then not to transition. This way the loop won't happen 👍

Only one thing is unclear: we can't choose more than one link type at a time in this post-function and our link has the same name for inward and outward link. And I haven't checked yet is it working for both or not?

But anyway thanks 🙏
I'm marking your answer as accepted ✅

With kind regards
Slava

[Slava Gefen]

@David Fischerthanks David! I just did it, but with the help of JSU, it has the relevant precondition!

Thanks for involving 🙏

[Radek Dostál]

I tried this with an issue link type locally which has identical outward/inward names, exporting the workflow to an xml shows this:

<function type="class">
  <arg name="field.copyFieldSource1"></arg>
  <arg name="textValue">-1</arg>
  <arg name="scopeSource-linkEnd"></arg>
  <arg name="maxAllowed-integerValue"></arg>
  <arg name="uuid">d8eff3c1-c2ed-478e-b746-921276ee0f5c</arg>
  <arg name="workflowName-textValue">(Xray) Default Workflow : Test Execution,Test Plan</arg>
  <arg name="performTransitionAsUser-user"></arg>
  <arg name="scopeType">ISSUE_LINKING</arg>
  <arg name="destination-scopeTarget">LINK_END</arg>
  <arg name="full.module.key">com.googlecode.jira-suite-utilitieslinkedtransition-function</arg>
  <arg name="scopeDestination-linkEnd">11621:OUTWARD</arg>
  <arg name="preconditionAwareFunctionMode-textValue">ALWAYS</arg>
  <arg name="source-scopeTarget">ISSUE_IN_TRANSITION</arg>
  <arg name="integerValue">1</arg>
  <arg name="scopeDestination-jql"></arg>
  <arg name="class.name">ch.beecom.jira.jsu.workflow.function.linkedtransition.LinkedTransitionFunction</arg>
  <arg name="scopeSource-jql"></arg>
  <arg name="status"></arg>
</function>

This line in particular:

<arg name="scopeDestination-linkEnd">11621:OUTWARD</arg>

Hints towards being specific to a direction. I wasn't too convinced though so I decompiled the .jar and followed the lines for a bit until I ended on this:

switch (linkEnd.getLinkDirection()) {
    case OUTWARD:
        result = linkCollection.getOutwardIssues(linkEnd.getLinkType().getName());
        break;
    case INWARD:
        result = linkCollection.getInwardIssues(linkEnd.getLinkType().getName());
        break;
    case ANY:
        result = linkCollection.getAllIssues();
}

Which confirms for me it's specific (linkCollection internally in Jira contains 2 separate maps, so each method for either outward/inward only looks in that particular map, but not both).

Since 'ANY' does not seem possible to specify, as far as issue link goes, then I'd say this seems to require 2 different functions, one for each of the different link direction.

I would, actually, try to modify the xml manually and replace OUTWARD to ANY (e.g. exporting, modifying, importing back, or replacing it in db), but of course no guarantees since it bypasses what the plugin allows in webUI. Seems that it should work, on first brief look around, but it's really not that great to do anyway, more of a curiosity killed the cat sort of an experiment.

^ nevermind that, if it did work it would include all issue link types, not just the specific one you're after