We have an internal incident ticket where automation and internal teams will create incident tickets using 'Affected services' field to indicate which services are affected then indicate on a checkboxes custom field `Impacted Services` where the same values names are available from both `Affected services` and `Impacted Services`. This allows cloning the ticket into downstream customer facing portals who have the indicated affected services in their contract and display the field to them in their respective tickets. This is in an effort to workaround the limitation of 'Affected services' not usable by unlicensed service management users (aka customers).
The problem I'm facing is using the "Advanced Branching" automation block to iterate over each name of an 'Affected services' value. When I capture the 'Affected services' as a smart value it is replacing each value of the 'Impacted Services' field, it thinks the field is empty each time it iterates on to the next value.
Am I using this correctly? Why doesn't it add the new values instead of starting empty each iteration? Is there some other way I can capture the list of all values from one field and transpose them to another field? I've tried the same with 'Labels' and it behaves the same starting with an empty 'Labels' value for each iteration.
Here you can see it works fine with only 1 `Affected services` selected:
If I select more than 1 `Affected services` value it exhibits the unintended behavior, where you can see it tries to set the value twice, each time starting with a value of "None".
Here are some screenshots of the rule, the smart values and logging are just for debugging, the trigger is editing the issue to make for easier testing, but the same behavior is observed with create issue trigger as well.
Hi @Darren Nicas -- Welcome to the Atlassian Community!
Yes, this scenario is solvable...but not with advanced branching.
First some information about branches in rules:
And so for your rule, the results are unpredictable, and the issue edits repeatedly walk-over each other.
For your scenario, a possible solution is to perform one single edit. Using text functions and a list iterator, create the JSON to perform the edit of the multiselect field, as described here: https://support.atlassian.com/cloud-automation/docs/advanced-field-editing-using-json/#Multi-select-custom-field And then use that JSON string in a single Edit Issue action.
I recommend first creating your JSON expression and writing it to the audit log until it works as you expect for all cases: 0, 1, >1 values selected. Then you can add it to the edit.
Kind regards,
Bill
Hi @Darren Nicas --
I was going to write something like what @Bill Sheboy wrote, but not as eloquently. :-}
I was thinking about the 2nd case though, and it is kind of odd that even though each edit action runs asynchronously, it seems highly unlikely to me that they'd run in exact sync, and since the JSON you're using is supposed to add a value rather than replace it, it's odd that you don't get at least some of the right values some of the time.
But anyways, yeah, you should be able to do this with a single Advanced Edit, using this handy JSON function, asJsonObjectArray. Something like this:
{"fields": {"customfield_10219" : {{issue.customfield_10033.name.asJsonObjectArray("name")}}}
Dangit, should have tested first.
Of course Bill is right, and man, I feel like we tried this before somewhere and stupid Automation doesn't actually let you treat multi-select field values as actual lists, so I had to iterate through values, just like Bill recommended:
{"fields": {"customfield_10219" : [ {{#issue.customfield_10033}} { "value" : "{{.}}" } {{^last}},{{/}} {{/}} ]}}
Haha I went back and found when we I did this before, and once again I forgot how to use the dang function. In this case we want value, so this is super easy and clean:
{
"fields": {
"customfield_10219" : {{issue.customfield_10033.asJsonObjectArray("value")}}
}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks, Darryl. I am going to start book marking these as stuff like this repeatedly comes up. And remember the possible "gotcha" noted in the earlier thread when the attribute names need to change between the field definition and attributes. (e.g., id versus value)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for the quick responses @Bill Sheboy , @Darryl Lee . Appreciate the comments, with both of them I was able to come to a solution that works for me :).
{
"fields": {
"customfield_10219": {{issue.customfield_10033.asJsonObjectArray("name").replace("\"name\"","\"value\"")}}
}
}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ah, I forgot you were using Affected Services which is a special field from Insight so yeah, you need to use the replace() function like I did before, haha. So glad you figured it out.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.