You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
Next: Root
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
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.
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.
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.
Thank for your support.
Best,
Matthieu
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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:
Here is the lookup rule.
I added an audit log action to see what's in the lookupIssues variables.
The branch rule is as follows.
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.
And finally I added a log to check if the branching path runs for each of the entries in the list.
-----
The audit log of the rule:
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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:
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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:
Variable:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.