Automation update approvers multi user picker for each

[Tiago]

Basically I'm trying to create an automation where I have an API that receives email addresses. In the "advanced branch for each" component I call the Jira API to get the accountId by the email address and update the approvers field (Multi picker user) with the JSON below in additional fields.

{ "update": { "Approvers": [{ "add": {"id":"{{webResponse.body.accountId}}"} }] } }

The problem is: Sometimes it works perfectly and other times it only adds one approver, but there are others.

I don't know if it would be a bug, but since it doesn't always work the same way, I have to find another way to do it.

I'm following the articles below, with the growth of for each e-mail address. What could be causing the problem. Any ideas? Thanks.

https://confluence.atlassian.com/jirakb/retrieve-data-with-jira-rest-api-in-automation-to-update-issue-fields-1319243229.html

https://confluence.atlassian.com/jirakb/dynamic-update-the-approval-in-jira-work-management-projects-1402408714.html

[Tiago · Accepted solution]

For those interested. In my case, I had a "simple" idea that managed to do what I was looking for.

Inside the foreach, after updating the approvers field, I call "Re-fetch Issue", then an if validating the field does not contain that Id. If it does not, I update it again.

The process is executed asyn, it will trigger a new thread for server and force the field to be updated. Its a "double-check" the value is correct.

[Marc - Devoteam]

Hi @Tiago Ervatti 

Welcome to the community.

Whenever you ask for help with an Automation Rule it will help us to help you if you provide:

1. what type of project is this (e.g., company-managed, team-managed, etc.), 

2. images that show your complete rule.

3. images showing the details of any relevant actions/conditions/branches.

4. images showing the Audit Log details for the rule execution.

5. Explain where the issue is.

These questions are not for not willing to help, but to have community members understand on how your automation works.

[Bill Sheboy]

Hi @Tiago Ervatti -- Welcome to the Atlassian Community!

Are you describing a single web response could contain multiple accountId values, or something else?

If the web response could contain multiple values, you could iterate over them in the dynamically created JSON expression to add them.

If instead there are multiple calls to the REST API, each one returning one accountId to add as an approver, the rule could use advanced branching to add them one by one.

Kind regards,
Bill

[Tiago]

It's the second option @Bill Sheboy .

I have an array of email addresses split with "," in the foreach. I call the Jira API with one email at a time (https://xxx.net/rest/api/3/user/search?query={{Email.urlEncode}}) and it returns an accountId {{webResponse.body.accountId}}.

In the same foreach, I update the "approvers" field with the Json bellow to add all the accountId returned from Jira according to the email address.

Sometimes, all of them are added, other times only one.

Thanks for help.

[Bill Sheboy]

Thanks for that information, and there are multiple causes for that symptom.  Seeing the complete rule and audit log details for the rule executions (as @Marc - Devoteam requested) may help to confirm these.

For example...

Perhaps the REST API call does not return a value for one-or-more of the email addresses, leading to an attempt to add an empty value.  That one seems unlikely...

The most likely cause is rule branches which could be on more-than-one-thing run in parallel and asynchronously.  And so I wonder if the updates are failing due to collisions.  Or, it is working but the results are checked too soon while the updates are in progress.

Let's assume it is a branching problem from parallel processing.  One possible solution is using a different endpoint, a dynamic regular expression, and add all the Approves with one edit:

• Use the endpoint Get All Users, which can return up to 1000 users (I think)
• Create a dynamic regular expression based on the email address list, storing that in a variable.  For example: (address1|address2|address3)
• Use the regular expression to extract the users needed; this may require use of inline searching techniques by flattening the relevant fields from the web response
• And use that result to create a single, dynamic JSON expression to add the Approvers with one Edit Issue action

[Tiago]

Hi, 

I created a simple and isolated automation. A variable with many "Accountid" separated by "," foreach split (","), and update the approvers field with a single Id at a time and the problem persists.

Attached the automation. For test, change the summary field of any issue and update the accountIds variable with valid and active Ids separated by "," in the automation.

All Ids always appear in the log, but the field is updated randomly. Sometimes all Ids, sometimes just one, just another etc.

I believe it has to do with asynchronous processes as you mentioned. It seems to be a problem in the component.

I'm thinking... set the variable with Ids inside the foeach (simulating the Jira API call) and outside the foreach, update the field all Ids at once.

Could you help me with this? Thanks.

https://drive.google.com/file/d/1JurG-c0dsshf1zaT0iYDIEBz3I6HCQHX/view?usp=drive_link 

[Bill Sheboy]

First, when asking for automation help please post images in your question of your actual rule and audit log details showing the rule execution.  Providing the exported rule JSON only helps in limited cases.

Fortunately, I am in the process of writing my own compiler for Jira automation rules and so am quite familiar with rule JSON details...and so I know that JSON cannot work as you describe: the rule is disabled, and does not set the value of the variable which is used in the advanced branch.

Assuming you have a rule which does extract the Description data, it is likely the branching is causing the problem.  And because of that same reason, a variable cannot be created within the branch and used afterwards for two reasons:

• With the parallel and asynchronous processing, any variable created inside the branch processing only exists for each pass through the loop.  It is thrown away when the pass finishes.
• Even if the variable was available later, such branches are not guaranteed to complete until the last step of the entire rule.  And so the rule steps immediately after the branch often start executing before the branch finishes looping.

I believe the REST API approach I described may work, although I have not tried it for this scenario.

[Tiago]

For me, this is a bug in foreach. Does it make sense to open a ticket? Is there already one open about this? Thanks.

Prints:

Foreach

Update Approvers Field

Log with Ids and update success

[Bill Sheboy]

This is how branches are designed to work, and so creating a "defect" may not help.  The likely response from Atlassian Support would be: the rule is repeatedly trying to update the same issue's field in a short window of time, and so is colliding with its own updates.  Essentially: the last one to process will win.

Here is the suggestion to make branch processing configurable: https://jira.atlassian.com/browse/AUTO-32

The item has shown as "in progress" for 6 months, and Atlassian has not disclosed what they are actually building.  In that suggestion there is an alternative workaround to what I suggested, although it is limited to 10 items and uses a risky, recursive rule approach.  (The risks are the looping could halt rule execution due to service limits, and debugging such rules is challenging.)

Two other things of note in the rule you show:

• Because of what the rule is doing (branching and adding to the multiple-selection user picker field), the Re-fetch Issue will not help (or hurt) as the updates are likely to collide regardless.
• When using created variables and branch variables, I recommend always using a variable name which cannot collide with built-in ones.  For example, using varAccountId rather than accountId.

[Tiago]

 @Bill Sheboy  I saw your comment on the open request link for attlasian. Thanks for your help and for increase. Regards