Is it possible to address the "most recent" work item within a "For Each" Branch

[Oliver Moore]

Hi,

I have the following rule which is intended to do the following:

1. Get all of the possible options form a custom field select list
2. For each option
3. Filter those I don't want
4. Create a clone of each
5. Link to the trigger issue
6. Do some actions of the clones (for example, set request type, copy form etc.)

What I am finding is that within the "for each" branch, other than creating the clones all of the actions are applied to the trigger issue. 

I can work around this in some areas (for example, changing the link so it addressed the trigger item not the clone. But not for others (circled in red).

Is there a way to avoid this, or do I need to have a 2nd rule which runs on the linked items of the parent and updates the linked clones.

[Bill Sheboy · Accepted solution]

Hi @Oliver Moore 

Currently, it is not possible to nest branches.  And, because branches on more than one thing process in parallel and asynchronously, you cannot add another branch later in the rule to add the comments to the created work items.

For your scenario, one possible work around is using the Send Web Request action to call the REST API for add comment inside the branch.  If you want to try this approach, here are some references to help:

• https://community.atlassian.com/forums/Jira-articles/Automation-for-Jira-Send-web-request-using-Jira-REST-API/ba-p/1443828
• https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/#api-rest-api-3-issue-issueidorkey-comment-post

Another possible workaround uses two rules, although that is a brittle approach due to possible synch / outage impacts:

1. In your current rule, a comment cannot be added when the work item is created.  Instead, add some indicator to another field for the comment to be added later
2. In a new rule, triggered on work item created and with the option to allow rule triggering enabled, check for that indicator.  When it is present, add the comment and clear the indicator.

Kind regards,
Bill

[Oliver Moore]

@Bill Sheboy  - thanks. I was considering the 2nd rule approach based on a trigger from rule 1 once it's cloned for the last option in the list. I really like the API approach though - I will see if I can get that to work first. Thanks!

[Oliver Moore]

Just to close this out - I got this working using the webhooks. Note this is a service desk project rule. The final rule came out as follows:

1. Got a list of all the options from a select list
2. Made it a variable
3. Iterated it
4. For each iteration
   1. Created a clone <- Step 4
      1. Including figuring out how to set the request type via advanced rather than the autoamtion action - Great article here.
   2. Linked the clone back to the trigger issue <- Step 5
   3. Web request to get the ID of the form attached to the source issue <- Step 6
   4. Grabbed the form ID  <- Step 7
   5. Copied the form from the source issue to the destination issue  <- Step 8

What I have run out of time for is really making steps 6 to 8 work. In the end step 8 is just copying all the forms on the source (of which there is always one) - I couldn't get the POST body right and kept getting

{"errors":[{"status":400,"code":"BAD_REQUEST","title":"There was an issue with your request","detail":"1 error found in JSON: (1) /ids(0) should be a UUID"}]}

from this POST body:

{

"ids": [
{
"value": "df656798-1448-45d2-ba9d-e1470d86695e"
}
]
}

If anyone knows what I'm doing wrong on the copy forms POST I'd love to know. 

I'd also like to highlight this which got me started down this road.