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.

[Bill Sheboy · Accepted solution]

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

[Rees_ Ian]

Apologies I forgot to add the image.  I have highlighted in yellow where I am trying to branch and you are right I am trying to branch in a branch.

[Rees_ Ian]

Thanks @Bill Sheboy I can see now why I had a branch in a branch and now I have removed the outer "For JQL" it makes sense and runs as far as 

key IN ( {{lookupIssues.parent.key.distinct.split(",")}} ) AND issueType = Epic

which fails with NO ISSUE: "(key IN ( [ITP-nnn], [ITP-nnn] ) AND issueType = Epic) AND (project in (nnnnn))" - Error in JQL Query: Expecting either a value, list or function but got '['. You must surround '[' in quotation marks to use it as a value. (line 1, character 11)

it looks as though somehow I need to parse out the square brackets to get valid JQL

[Rees_ Ian]

Here is the rule and error

[Rees_ Ian]

Thanks for your help @Bill Sheboy I think I'm through the hard bit - I parsed the JQL string with a couple of temporary variables and the last bit of assining the variables now should be straightforward - much appreciated your help

[Rees_ Ian]

What you can't see from above is the parse as follows

varStrA = {{lookupIssues.parent.key.split(",")}}
varStrB = {{varStrA.remove("[")}}
varStrC={{varStrB.remove("]")}}

Couldn't see a way to reuse variables without creating a new one :( but works

[Bill Sheboy]

Awesome, and I am glad you figured it out!

You can also chain those things together in one step:

{{lookupIssues.parent.key.split(",").remove("[").remove("]")}}

[Rees_ Ian]

Interestingly the chain didn't work

varChainedStr = [], [], [], []

versus

varUnchainedStrC = ITP-352, ITP-352, ITP-352, ITP-353

[Rees_ Ian]

However 

varChainedStr = {{lookupIssues.parent.key.remove("[").remove("]")}}

varChainedStr  = ITP-352, ITP-352, ITP-352, ITP-353

varUnchainedStrC = ITP-352, ITP-352, ITP-352, ITP-353

So don't need the split :)

Thanks for all of you help @Bill Sheboy 

[Bill Sheboy]

Yup...some of the "list" functions return a list (an object) and some appear to return a text collection (a delimited list of text).

It is often good to write values to the audit log first to confirm what is happening, versus what the documentation says  :^)