Unable to modify items inside foreach branch

[Bohumil Klimek]

Hello community, I have the following problem, and I suspect that I'm just doing something wrong. Therefore, any help would be greatly appreciated.

My use case is to identify all items with empty fix versions and fix them with Jira automation. I'm using a trigger where the sprint value changes for a Jira ticket, such a sprint is active, and such a sprint contains a particular string.

1. I have the following branch where I would like to modify certain Jira tickets from lookup work items (see screenshot). Based on the audit log, which shows all items in the current sprint (which is the point of this data set), this should be working fine.

2. Next is my branch, where I would like to work with the mentioned lookup work items (see screenshot)

3. Next, I'm doing a comparison for the empty fix version (see screenshot)

4. Next I'm trying to edit all items that match the previous condition (see screenshot)

5. And finally, sent a Slack message for each of the modified tickets. 

Examining the audit log, I can see a properly populated lookup table with all items in the current sprint (based on the trigger). Even Slack is able to translate {{MyIssue.FixVersions}} properly, but I suspect issue somewhere in if or editing given issues. Any idea how to achieve my goal?

[Bill Sheboy · Accepted solution]

Hi @Bohumil Klimek -- Welcome to the Atlassian Community!

The purpose of the Lookup Work Items action is to gather work item data as a batch, such as for summing on a field.  It does not allow accessing the items as work items for edit.  And so when your Advanced Branch iterates over the data, it cannot access the actual work item.

Without seeing your entire rule for context...

You could remove the Lookup Work Items action and instead use the JQL from that action in a branch on JQL to access and edit the work items.

Kind regards,
Bill

[Bohumil Klimek]

Hello @Bill Sheboy 

It does not allow access to the items as work items for editing, so when your Advanced Branch iterates over the data, it cannot access the actual work item.

Ah, it makes sense. What you said wasn't clear to me when I tried to compile this rule.

Without seeing your entire rule for context...

Please, here is the screenshot....

You could remove the Lookup Work Items action and instead use the JQL from that action in a branch on JQL to access and edit the work items.

Can you please describe this in more detail? Many thanks in advance.

[Bill Sheboy]

Following what I stated, the rule could look like this:

• trigger: value changed for sprint (with your conditions added)
• branch on related work items: selecting the JQL option and using the JQL you currently have in the lookup...adding the condition to check the Fix Versions field: sprint = "{{issue.sprint.name}}" AND issueType NOT IN subTaskIssueTypes() AND fixVersion IS EMPTY
  • action: edit the work item 
  • action: send the Slack message

This will send a Slack message for each work item.

If instead you wanted to send one Slack message noting all of the work item as a list, then it would make sense to use a Lookup independently from the branch:

• trigger: value changed for sprint (with your conditions added)
• action: lookup work items, with the modified JQL
  • sprint = "{{issue.sprint.name}}" AND issueType NOT IN subTaskIssueTypes() AND fixVersion IS EMPTY
• smart values condition
  • first value: {{lookupIssues.size|0}}
  • condition: greater than
  • second value: 0
• action: send the Slack message, referencing the list of work items as described here: 
  • https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Lookup-issues
• branch on related work items: selecting the JQL option and using the same JQL as above: sprint = "{{issue.sprint.name}}" AND issueType NOT IN subTaskIssueTypes() AND fixVersion IS EMPTY
  • action: edit the work item 

This adds an additional Smart Values Condition so the rule does not proceed unless there are results in the lookup results.  Then it sends a single Slack message before the work items are edited in the branch.

[Bohumil Klimek]

@Bill Sheboy, many thanks for moving me to the right track. You get exactly what I need. One small detail... everything works perfectly, but the issue which caused the rule trigger is for some reason ignored in given JQL branch even though it should be part of it.... any idea?

[Bill Sheboy]

Ah, yes...this is a known limitation of the JQL branch: it automatically excludes the trigger work item to prevent accidental endless loops.  Essentially, it adds a clause to the branch JQL behind the scenes:

AND key != {{triggerIssue.key}}

As you also want to update the trigger work item, please add another Edit Work Item action before the branch.  Assuming you used the second version of the rule I showed, that would be this, with the added action bolded:

• trigger: value changed for sprint (with your conditions added)
• action: lookup work items, with the modified JQL
  • sprint = "{{issue.sprint.name}}" AND issueType NOT IN subTaskIssueTypes() AND fixVersion IS EMPTY
• smart values condition
  • first value: {{lookupIssues.size|0}}
  • condition: greater than
  • second value: 0
• action: send the Slack message, referencing the list of work items as described here: 
  • https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Lookup-issues
• action: edit the work item, to set the Fix Version to your value
• branch on related work items: selecting the JQL option and using the same JQL as above: sprint = "{{issue.sprint.name}}" AND issueType NOT IN subTaskIssueTypes() AND fixVersion IS EMPTY
  • action: edit the work item 

[Bohumil Klimek]

Ah, makes sense.

Thank you for your support.

[Marc - Devoteam]

Hi @Bohumil Klimek 

Welcome to the community.

In the condition in the branch set the field to be check if empty to {{issue.fixVersions}}

You don't have to specify MyIssue in this variable the issue key is stored, but the branch is based on the lookup action, so it acts for each issue found in the lookup and for each issue you wand a condition to see if the Fix Versions fields is empty and if so set it with the value you require

[Bohumil Klimek]

Many thanks for the hint, but...

After your suggestion, it still identifies only 1 issue with an empty fix version instead of 3, which have empty fix versions in the current sprint—see screenshot.

However, sending a Slack message (in the same branch) processes all of them, which is weird.

[Marc - Devoteam]

Hi @Bohumil Klimek 

You lookup needs ton consist of a JQL that finds the issues in the sprint with no Fix Version, then you also won't need the condition in the branch as the found issues are the ones with no Fix Version

But also you trigger is strange as it acts on a field change, what field change and this is always on a single issue?