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

Automation question - looping through lookup issues and setting fields outside the loop

Rees, Ian

I have an automation rule that triggers when a version is released. When a version is released, I want to iterate through the stories, tasks and bugs in the release and find those that are children of Epics. Then for those Epics, I want to update two custom fields. I am nearly there - see attached. But how do I then update two custom fields in the Epics (ITP-352 and ITP-353 in the example) with the values in the variables, varTotalStoryPoints and varCountTotalChildIssues. audit log for automation.PNG

Accepted answers

Bill Sheboy

Hi @Rees, Ian -- Welcome to the Atlassian Community!

Reading your use case and looking at your rule, it appears you only want to update the Epics' custom fields, summing information from their child issues. Is that correct?

If so...you cannot nest branches in rules, and thus other approaches can be used.

Next question: are the epics assigned to the release? The answer will determine how to proceed.

Yes, the epics are in the release also

In this case, just branch on the epics instead in the rule...

trigger: version released
branch: on JQL to any issueType = Epic AND fixVersion = "{{version.name}}"
- action: lookup issues for the child issues of the epic which are in the release
- action: edit issue to change the epic for the custom fields, using the lookup values, such as {{lookupIssues.Story points.sum|0}} and {{lookupIssues.size|0}}

No, the epics are not in the release

Similar to above, except the first step is to find the epics so you have them to walk for the branch...

trigger: version released
action: lookup issues on JQL to find all issues in the release which are children of epics
branch: on JQL to the epics with key IN ( {{lookupIssues.parent.key.distinct.split(",")}} ) AND issueType = Epic
- action: lookup issues for the child issues of the epic which are in the release
- action: edit issue to change the epic for the custom fields, using the lookup values, such as {{lookupIssues.Story points.sum|0}} and {{lookupIssues.size|0}}

Kind regards,
Bill

All comments

Bill Sheboy

Hi @Rees, Ian -- Welcome to the Atlassian Community!

Reading your use case and looking at your rule, it appears you only want to update the Epics' custom fields, summing information from their child issues. Is that correct?

If so...you cannot nest branches in rules, and thus other approaches can be used.

Next question: are the epics assigned to the release? The answer will determine how to proceed.

Yes, the epics are in the release also

In this case, just branch on the epics instead in the rule...

trigger: version released
branch: on JQL to any issueType = Epic AND fixVersion = "{{version.name}}"
- action: lookup issues for the child issues of the epic which are in the release
- action: edit issue to change the epic for the custom fields, using the lookup values, such as {{lookupIssues.Story points.sum|0}} and {{lookupIssues.size|0}}

No, the epics are not in the release

Similar to above, except the first step is to find the epics so you have them to walk for the branch...

trigger: version released
action: lookup issues on JQL to find all issues in the release which are children of epics
branch: on JQL to the epics with key IN ( {{lookupIssues.parent.key.distinct.split(",")}} ) AND issueType = Epic
- action: lookup issues for the child issues of the epic which are in the release
- action: edit issue to change the epic for the custom fields, using the lookup values, such as {{lookupIssues.Story points.sum|0}} and {{lookupIssues.size|0}}

Kind regards,
Bill

Rees, Ian

Thanks Bill -

It appears you only want to update the Epics' custom fields, summing information from their child issues. Is that correct? - Yes that is correcty

The Epics are not in the Release. The epic may contain multiple issues that are released in different releases. I will try the branch suggestion. Thanks for your help

Rees, Ian

Thanks @Bill Sheboy

I am trying to follow the logic and have tried this but am hitting a few problems. May I ask few questions

1. Re - "

trigger: version released
action: lookup issues on JQL to find all issues in the release which are children of epics"

I have done this in my rule (see attached). Why is it necessary to do the lookup again as does it not produce the same results that I am iterating through with the trigger

2. "branch: on JQL to the epics with key IN ( {{lookupIssues.parent.key.distinct,split(",")}} ) AND issueType = Epic"

When I try to enter Branch as the next component in my automation, Branch is not an option - any idea why that would be ?

3. What is lookupIssues.parent.key.distinct,split(",")}} doing ?

Thanks Ian

Bill Sheboy

Your #1 item)

For the "epics are not in the release" approach, the first lookup was to find the epic's keys. Then inside the branch, and as each epic is walked, a second lookup was used to gather the stats for the relevant issues.

Your #2 item)

This could be because you are already in a branch, and so the editor prevents that. Please post an image of your current rule, highlighting where you are trying to insert the branch.

Your #3 item)

What does lookupIssues.parent.key.distinct.split(",")}} do...
- That lookup was on all issues in the release which have an epic parent
- And so we only care about the parent's keys
- And we do not want them repeated (e.g. multiple issues in an epic), so we select them with distinct (I just noticed my typo of a comma rather than a period, which I fixed)
- With that resulting list, we then want to use split() to create individual parent (epic) keys to walk in the advanced branch