Can you create automation to copy a jira issue so the children's order are exact?

[Phillip_Dang]

Hello. I have a challenge. 
I have a "templated" jira issue with children and grandchildren.  These jira issues must be exactly replicated even in the order of the children.

I have been successful in copying the jira issue along with the children and grandchildren in its entirety BUT...
the order of the children is not the order as the original.

Example:

Jira-100 A
  > Jira-104 AA
  > Jira-105 BB
  > Jira-110 CC
  > Jira- 120 DD
     > Jira - 153  DDA
     > Jira - 167. DDB
  > Jira - 123 EE

Above is my jira "template" issue that I want to replicate.  I created an automated script that loops through the children and subsequent grandchildren and creates a copy BUT not in the right order.  It produces something like this:

Jira-400 A
  > Jira-401 CC
  > Jira-402 BB 
  > Jira-430 DD
     > Jira - 432  DDB
     > Jira - 431 DDA
  > Jira-434 AA
  > Jira-433 EE 

Is there a trick to this?

[Bill Sheboy · Accepted solution]

Hi @Phillip_Dang 

That is not possible when using a branch to loop over issues in the rule.

Branches which could be on more-than-one-thing are processed in parallel and asynchronously.  There is no guarantee when such a branch will finish, up until the last step of the rule.  Please look here to learn more: https://support.atlassian.com/cloud-automation/docs/jira-automation-branches/#Ordering-of-branch-executions

I believe the only methods to preserve the issue order (parent to list of child issues) are:

1. With an automation rule, add them one at a time, with no branching over the issues
2. With an automation rule, use a complicated webhook triggered rule mechanism to progressively add the issues, one by one.  That will not work if there are more than 9 issues due to automation service limits, and if it fails recovery would be challenging.
3. Build an application which can process the issues sequentially, using the REST API to create them
4. Use a marketplace addon which can preserve the order, likely using the same methods as for #3 above

Kind regards,
Bill

[Phillip_Dang]

Thank you sir!

[Anton Zubets]

Hi @Bill Sheboy 

Thanks for the clarification above.

I had an impression that when Atlassian is saying that:

Branches on multiple issues (such as 4 sub-tasks) will run in parallel with no guarantee one will finish before the next one starts. Therefore, you cannot rely on changes between branches.

it actually only means that such a branch will be executed as a parallel process from the main flow of the automation (where that branch was used). But it doesn't mean that inside such a branch the actions will be executed in some random order because Jira will be running all of them in parallel.

Do you mean that this is what is actually happening in case of such a branches?

For example, if we are talking about an automation similar to what @Phillip_Dang  was describing above :

1. LookupIssues - select all the child issues of the "template" epic and use "ORDER BY created" to ensure keeping the required order
2.1. FOR Branch using the {{lookupIssues}} smartvalue to iterate over those child "template" issues
2.2. Clone or Create Issue block to create a copy of the template issue

then in this case Jira will ignore the order of the issues in the {{lookupIssues}} when executing the branch (steps #2 and #3 above) because it will be running step #3 in parallel for multiple issues from the {{lookupIssues}} list?

It kind of doesn't really make any sense, frankly speaking. Cause such "parallelism" is not bringing any value when it's inside the branch. While it's totally understandable having each branch (in its entirety!) to be executed in a parallel process from the main automation flow but then inside the branch the order of execution should still remain sequential.

Regarding your suggestions above, can you, please, advise on how such requirement (to have child issues cloned in a certain order) could be implemented without using branches:

1. With an automation rule, add them one at a time, with no branching over the issues

Can you also recommend some of the relevant addons, which could solve this issue?

4. Use a marketplace addon which can preserve the order, likely using the same methods as for #3 above

[Bill Sheboy]

In my experience and observations, the items processed by such branches run in independent processes running in parallel and asynchronously.  This likely helps with rule performance as the branch could contain conditions or actions with nondeterministic run times (e.g., Send Web Request), and so blocking is reduced.

There is an open suggestion to add options for sequential versus parallel processing of rules, or at least a "wait until branch completes", similar to the Send Web Request action.  Please watch / vote for this item to see any progress: https://jira.atlassian.com/browse/AUTO-32

Regarding workaround #1, this would require first gathering the issues using the Lookup Issues action, then directly reference the issue-to-clone's fields.  For example, using get() or smart value, list filtering.  {{lookupIssues.get(42).summary}}  This will not work for all cloneable fields as the Issue Create action may not take smart values to set some fields.

Regarding workaround #4, I have not used any of the marketplace, issue cloning apps, and am unable to recommend any.  I recommend quickly documenting your needs and then trying some of them from the marketplace to see which better meets your needs.

[Anton Zubets]

Hi @Bill Sheboy ,

There is an open suggestion to add options for sequential versus parallel processing of rules, or at least a "wait until branch completes", similar to the Send Web Request action. Please watch / vote for this item to see any progress: https://jira.atlassian.com/browse/AUTO-32

My point is not about having a branch running in the same process with the main automation flow :) That's totally fine to have a branch run as a separate process, as this is a well documented behavior.

My point it about having all the actions inside the branch run in the same way like the main automation runs - without any parallelism, just executing actions step by step. Currently there is nothing in the documentation which tells us that we should expect actions inside a branch to be applied to the looped through objects in a random order and all of us expect it to just run sequentially taking the looped through objects one by one in the sequence they were provided at the beginning of the branch (e.g. as the result of the Lookup Issues action). But this appears not to be the case :(

Hope it's more clear that way.

Regarding workaround #1, this would require first gathering the issues using the Lookup Issues action, then directly reference the issue-to-clone's fields. For example, using get() or smart value, list filtering. {{lookupIssues.get(42).summary}} This will not work for all cloneable fields as the Issue Create action may not take smart values to set some fields.

You mean to hardcode a certain number of Create Issue actions and in each of them refer to particular item in the lookupIssues? But how could we know in advance how many "template" issues there will be (in my case it's a dynamic number, not just one "template" epic, which is always getting "cloned")?
Unfortunately, it doesn't seem to be a viable solution in such case, while I'm already ready for any brutal/dirty hacks in order to get such Jira automation finally do what's required... 

Anyway, thanks a lot for your advices and continuous support of the community here!

[Bill Sheboy]

First a disclaimer: I am just another Jira user / community member.  I have no internal knowledge of the mechanics of the automation engine or the design decisions used.  My ideas / opinions are based on usage, observation, and what I see in the documentation.

Next on the hardcoding and cloned issue order: with a dynamic number of issues I believe the only options are marketplace addons or to build your own app using a sequential processing flow.

For branching, once inside the branch, the steps for a specific item process in order.  And for each item it is the processing as a unit (i.e., the steps inside the branch) which the documentation describes as running in parallel: https://support.atlassian.com/cloud-automation/docs/jira-automation-branches/#Ordering-of-branch-executions  This matches my observations of rule execution.

Again, I am just another user.  For your specific concerns for the rule engine, I recommend creating additional suggestions or working with your Jira Site Admin to contact the Atlassian Support team: https://support.atlassian.com/contact/#/