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; } } }

Clone linked issues from JQL Branch Rule and keep them in order?

Darryl Lee

I swear @Bill Sheboy has answered similar questions but I couldn't figure out if any of them fit my use case.

In a nutshell, I have a bunch of tasks linked to a "parent" Epic. (They aren't actual child tasks because they're under a different Epic. It's complicated and I'll explain it in a separate article if I get this working.)

So I'm using a Branch rule / related work items with the following JQL query:

issue in linkedIssues("{{certParentKey}}") order by issuekey

So yeah, the query returns ISSUETMP-6808 , ISSUETMP-6809 , ISSUETMP-6810 , ISSUETMP-6811, ISSUETMP-7298 , ISSUETMP-7302, in that order.

The thing is, the person who requested this automation would like those tasks to be kept in the same order.

And well, since we've been waiting 5 years for actual resolution of AUTO-32, the ticket formerly known as Allow switch between parallel and sequential execution of Automation Rules ... I can't figure out how to do this.

To paraphrase Princess Leia... "Help me @Bill Sheboy you're my only hope"

% telnet telehack
.starwars

Alternately: https://www.asciimation.co.nz/

Accepted answers

Hartik

you can’t reliably keep order when cloning from a JQL branch. Automation runs branch items in parallel, so even if the JQL is sorted, the clone actions don’t respect that order.

The only practical workaround is to add an explicit ordering field first, like a number or rank copied into a custom field, then sort the cloned issues afterward using that field. If order truly matters at creation time, Automation can’t do it today and AUTO-32 is still the blocker.

Bill Sheboy

Hi @Darryl Lee

Until a sequential branching feature is added to rules, there are a few workarounds, each with their own cost / benefits / risks. Some of these will not work with linked work items, but I will list all the ones I can think of regardless.

Some shared risks for the workarounds are:

although there is an upper limit on links to a work item (2000, I think), a solution to handle 0-to-many for cloning may lead to rules exceeding several service limits
there are no built-in Jira constraints to prevent linkage cycles; this could cause an endless loop for walk-the-chain scenarios (e.g., A->B, B->C, C->A...oops!)
any rule which does several actions in a row could fail in ways difficult to clean-up
rule outages may obscure what did / did not happen, making "catching up" challenging
maintaining complicated rules is challenging and brittle for teams

#1) One-by-one creates

With a limited and known number of work items, add them one by one with actions
When a rule uses a single-item branch, that is run inline and can work around parallel processing (e.g., JQL branch on key = ABC-123)
Please test thoroughly! I recall the behavior of inline execution of single-item branches changed early after Code Barrel was acquired by Atlassian. As this behavior is undocumented, there is no guarantee it will not change in the future.

#2) Chained rules (FYI -- I would not recommend trying this one.)

assuming fewer than 10 linked work items...(and a lot of hope)
create a rule which identifies and clones the first linked work item, adding a "magic" value to it (e.g., custom field at the same time as the create)
a second rule, triggered on work item create, and with "Allow Rule Trigger" enabled, detects the magic value, identifies the next work item to clone**, and does so
that ** part above is left as an exercise for the reader, and likely involves dynamic JQL and list searching shenanigans techniques

3) Multiple rules with recursion

First rule gathers the work items to process, and then calls another using Send Web Request, passing the data needed in the request
Second rule uses the Incoming Webhook Trigger, processes one item, removes it from the list, and when more remain, calls itself with Send Web Request
RISKS: there is no documentation as to whether or not this approach is checked with the looping service limit although that could be validated with a couple of test rules to check if a header (or whatever) is added behind the scenes with Send Web Request to detect the request source...leading to the limit check failure
The general approach is outlined in this Atlassian team member article

#4) Build your own external app

create a service in a language which supports sequential loop processing
call that with Send Web Request

#5) Build your own Forge action???

I have not tried this, but perhaps a Forge app could be created to build a new rule action to sequentially add work items
I suspect a marketplace vendor may create / sell such a thing, although I have not searched for one

#6) Investigate marketplace apps / addons

I recall there are several cloning-related apps, and perhaps one fits your scenario with the linked work items

Good luck, Darryl, and let us know what you try. Thanks, sir!

Kind regards,
Bill

All comments

Hartik

you can’t reliably keep order when cloning from a JQL branch. Automation runs branch items in parallel, so even if the JQL is sorted, the clone actions don’t respect that order.

Bill Sheboy

Hi @Darryl Lee

Some shared risks for the workarounds are:

although there is an upper limit on links to a work item (2000, I think), a solution to handle 0-to-many for cloning may lead to rules exceeding several service limits
there are no built-in Jira constraints to prevent linkage cycles; this could cause an endless loop for walk-the-chain scenarios (e.g., A->B, B->C, C->A...oops!)
any rule which does several actions in a row could fail in ways difficult to clean-up
rule outages may obscure what did / did not happen, making "catching up" challenging
maintaining complicated rules is challenging and brittle for teams

#1) One-by-one creates

With a limited and known number of work items, add them one by one with actions
When a rule uses a single-item branch, that is run inline and can work around parallel processing (e.g., JQL branch on key = ABC-123)
Please test thoroughly! I recall the behavior of inline execution of single-item branches changed early after Code Barrel was acquired by Atlassian. As this behavior is undocumented, there is no guarantee it will not change in the future.

#2) Chained rules (FYI -- I would not recommend trying this one.)

assuming fewer than 10 linked work items...(and a lot of hope)
create a rule which identifies and clones the first linked work item, adding a "magic" value to it (e.g., custom field at the same time as the create)
a second rule, triggered on work item create, and with "Allow Rule Trigger" enabled, detects the magic value, identifies the next work item to clone**, and does so
that ** part above is left as an exercise for the reader, and likely involves dynamic JQL and list searching shenanigans techniques

3) Multiple rules with recursion

First rule gathers the work items to process, and then calls another using Send Web Request, passing the data needed in the request
Second rule uses the Incoming Webhook Trigger, processes one item, removes it from the list, and when more remain, calls itself with Send Web Request
RISKS: there is no documentation as to whether or not this approach is checked with the looping service limit although that could be validated with a couple of test rules to check if a header (or whatever) is added behind the scenes with Send Web Request to detect the request source...leading to the limit check failure
The general approach is outlined in this Atlassian team member article

#4) Build your own external app

create a service in a language which supports sequential loop processing
call that with Send Web Request

#5) Build your own Forge action???

I have not tried this, but perhaps a Forge app could be created to build a new rule action to sequentially add work items
I suspect a marketplace vendor may create / sell such a thing, although I have not searched for one

#6) Investigate marketplace apps / addons

I recall there are several cloning-related apps, and perhaps one fits your scenario with the linked work items

Good luck, Darryl, and let us know what you try. Thanks, sir!

Kind regards,
Bill

Darryl Lee

Thanks - good point on ranking after creation, although what they really want is to see those child tasks in order while viewing the epic.

Hum, will need to look at @Bill Sheboy 's suggestions.

Darryl Lee

Thanks for responding to the Bat-Signal, @Bill Sheboy (truly mixing the movie/tv references), I knew you'd come through.

#1) Alas, no, the number of linkedIssues is variable, depending on the type of certification

#2) My reaction while reading this was that I said "Oh god" then made this face:

(I was gonna use clip art, but eh, cool hat.)

#3) Hmmmmmaybe? I mean should the fact that an Atlassian team member wrote the article mean it's kinda sorta supported? Hahaha. Ok, yeah, I guess it's like an internal function instead of doing #s 4 or 5...

#4) Ah right, like a AWS Lambda job that accepts list of issues, and new parent, and then serially creates them? That doesn't sound awful, except the maintenance part.

#5) Oh god. Yeah, this is what @Caterina Curti and @Bryan Guffey would surely suggest. Also maintenance, but I guess at least I wouldn't have to worry about an AWS bill on top of it. (As miniscule as that would be.)

#6) We're too cheap for an app, and it also feels like overkill, but I'll take a look. Geez, there are so many. Maybe we really do need Personalized app recommendations in search results! (Kidding. I hate that idea.)

Ok, lots to chew on. Thanks!!

Bill Sheboy

Hi @Darryl Lee -- how about a maybe #7 approach:

Using the Bulk Create Issue endpoint, use list iteration over a lookup result for the linked work items to build the JSON message, and try adding them with one Send Web Request.

I could not find information if the items are iterated to add sequentially or in parallel, so testing would be required. And, this puts the entire burden on the rule-writer to manage all the cloned fields in the message.

Darryl Lee

Woof. I think there's a couple of issues with that. It's Bulk Create, not Bulk Clone. Reading the (admittedly sparse) docs, I don't see a way to reference a "source" issue to copy.

So I'd have to get pass it the full content of each child task I'm cloning? (I mean it's probably just Summary and Description, but what if I miss a field?)

But I'm now leaning towards #3 because despite the scariness of recursion, I do like the idea that everything stays within Automation. No external calls, no API calls. It's all blocks, so if somebody does have to figure out what the hell I did, they won't find some black box somewhere outside of Jira.

Nope, it'll be a black box in another rule. :-}

Welcome!

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

Quick Links

Find more posts tagged with

automation