Using Advanced Branching to iterate over a list of issues and performing an action on each issue.

Shaun Dunstan August 25, 2022

I recently read the following article: https://community.atlassian.com/t5/Automation-articles/Branching-over-smart-values-in-Jira-Automation/ba-p/1741935

This article mentions "Iterating over a list, such as a list of issues from Lookup Issues action, and performing an action on each of these issues"

I am trying to use the "Advanced Branching" action in order to update the summary of a list of issues, based on a customfield value in each of those issues.

Atlassian.PNG

The result of the above automation is not that each issue in the LookUp is edited.

The Issue that I am triggering this off is having its summary edited.

 

My desired outcome is that I provide a list of issues. For each of these issues I would like to pass out a customfield value on the issue (not included in the above automation to make it simpler) to the summary.

 

2 answers

0 votes
Matthieu Negrier September 6, 2023

Hi @Stefan Salzl

I think I'm facing the exact same problem as Shaun.

I get a list of issues from the "Lookup Issues" component, then I loop over {{lookupIssues}} and try to perform actions on each of the entries. Surprisingly, the "Edit Issue" component seems to only apply to the trigger issue (and only once!) while I can log the key for each entry.

You can see in the log details that there are 5 issues found whose key was printed, but that the trigger issue is the only one that was wrongly edited.

Screenshot 2023-09-06 at 17.52.09.pngScreenshot 2023-09-06 at 17.52.57.png

Thank for your support.

Best,
Matthieu

Matthieu Negrier September 6, 2023

To complete my previous description, if "Edit issue fields" is not the component to use in the branch path I didn't find the right component to edit the field of each of the entry (named {{child}} here).

Thanks.

Stefan Salzl
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
September 6, 2023

Hi @Matthieu Negrier 

could you please give mor details:

What exactly would you try to do from a functional perspective? What should your JQL result should show? 


Furthermore:

Could you please add another log action to just log the result of your LookupIssues action? Please also add a screenshot of your branch‘ configuration.

Best
Stefan

Matthieu Negrier September 7, 2023

Hi @Stefan Salzl

Thanks for your help.

The result I'm trying to achieve is to propagate the value of a custom field from one issue to its child issues. There is a branch rule to easily iterate an Epic's child issues, but I have other higher levels (Initiative and Legend) where this is not available.

That's why I'm trying to get the child issues of the trigger issue with a lookup rule that searches for issues whose trigger issue is the parent. Then I loop through the found list to modify each of the entries by setting a field with a value that I previously saved in a variable ({{specsURL}}).

Here is the rule:

FullRule.jpg

Here is the lookup rule.

Lookup.png

 

I added an audit log action to see what's in the lookupIssues variables.

LogLookupIssues.png

The branch rule is as follows.

LookupBranching.png

Then the edition of the issue in the For each path. This is the step where I want to modify the "URL Specifications" field of each of the entries in the list assuming that the block will apply to each entry because it is in the branching path.

EditIssue.png

And finally I added a log to check if the branching path runs for each of the entries in the list.

ChildLog.png

-----

The audit log of the rule:


AuditLog.png

I see the keys to the different rules found by the search step (there are 7). Then for the branching path, the "Edit issue" step only gives a single log for the trigger issue instead of being executed on each of the entries in the list which is iterated while the final log is correctly executed for each of the entries.

 

Thank you again.

Best,

Matt

Like Stefan Salzl likes this
Stefan Salzl
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
September 7, 2023

@Matthieu Negrier thanks for all the detailled information. Could it be that the edit action was created up front/before the branch and then moved? Sometimes actions/components can get glichy.

Would you please try to delete the edit action and recreate it wirhin the branch? Because from my perspective the rule looks correct.

And 1 further question:
Is the parent issue the triggerIssue? Is the hyrachy built by advanced roadmap?

Best
Stefan

Matthieu Negrier September 8, 2023

Hi @Stefan Salzl ,

Removing the Edit action and recreating it has no effect. It still applies to the trigger issue. Which is also surprising is that the action is executed once while the path is traversed 7 times. A hint could be the requirement to give the looped entries a variable name (here {{child}}) in the branching rule. In the audit log action, it is possible to reference it but not in the Edit action (which can be based on hardcoded input variable names).

The parent issue is indeed the trigger issue. It is started manually. We use advanced roadmap and have defined new hierarchy levels (Initiative > Legend > Epic > Story...). The example I shared with you is run on an Initiative issue. I also tried on other levels without success.

Best,
Matt

0 votes
Stefan Salzl
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
August 25, 2022

Hi @Shaun Dunstan and welcome to the community,

Could you please also provide a screenshot of your audit log and of your create variable action? that would give some more information.

Furthermore: Did you check the result of your lookupIssues? Does it return the expected list of issues?

Best
Stefan

Stefan Salzl
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
August 25, 2022

Furthermore:
As you would like to iterate over the list of issues and edit each of them: Is there a special reason to avoid using a JQL branch?

See the following screenshot:
image.png

eg. I do have "ISSUE-A", this issue has 3 other issues linked with "relates to" (ISSUE-B, ISSUE-C, ISSUE-D).
After the execution of the rule only the 3 linked issues (B-D) are editted.

Isn´t this the result you expected or did I miss any information?

Best
Stefan

Shaun Dunstan August 25, 2022

Hi @Stefan Salzl ,

Thanks for your response. I have been able to verify that my LookUpIssues is returning the correct issues.  In our current example it is intentionally only returning 1 issue.

Audit Log:

Audit Log.PNG

Variable:

Variable.PNG

Regarding JQL branching: It is my experience that when using a JQL branch, the value that is used to modify the list of issues is based off the trigger issue, not each issue itself.

ie:

JQL Branch from Issue A.
Issue A has a summary of "X"
Issue B has a summary of "Y"
I want to update the description of each issue to each issues summary.
Issue A will place value "X" into the description.
Issue B will place value "X" into the description.

In my requirements, I need the value to be specific to each issue.

I hope my example has provided clarity.

Neil Ashford
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
September 4, 2022

Hi @Shaun Dunstan,

As long as your action is inside the branch, smart values like {{issue.summary}} should refer to the summary of the issue you're looping over, instead of the trigger issue. To access the summary of the trigger issue within a branch, use {{triggerIssue.summary}}.

 

I found this in the docs, I hope it helps:

Smart-values in components defined for related issues will refer to the related issue by default. That is {{reporter.displayName}} will refer to the reporter of the sub-task (when looping over sub-tasks). You can however also access the issue that triggered this automation rule via {{triggerIssue}} (e.g. {{triggerIssue.fields.summary}}).

 

— Neil

Like Stefan Salzl likes this
Stefan Salzl
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
September 5, 2022

Hi @Shaun Dunstan 

As far as I understand your requirement Issue A is the triggerIssue. This only says it triggers the rule and the key is stored in the smart value triggerIssue. This does not need to be part of the result of your JQL. Within your rule a JQL branch can execute ANY JQL which means the result could be any other issue key (or a list of issues).

futhermore as your described:

Issue A already hast "summary X". So this issue would not need to be changed anyways. You just would like to have issue B the same summary as issue A so no need to edit issue A.

Please correct me if I´m wrong.

Best
Stefan

Suggest an answer

Log in or Sign up to answer