Rule Logs are running perfectly but behavior on issue is different

[Tomas Franco]

Hi,

I want to assign (both on creation and edition) a multiple selection custom field based on the products selected.

So for instance if user selects app1, app2, app3 (in customfield_xxxx1), I want to automatically assign team members user1, user2, user3 (in customfield_xxxx2).

The rule goes like this:

Trigger: When Value Change (for customfield_xxxx1)

Create lookup Table: Mapping: Key: "appX" -> Value: "userID"

Advance branching: on the smart value: {{fieldChange.tostring.split(',')}} as DigitalProducts

Then: Edit Issue (advanced)

{
   "update": {
      "customfield_xxxx2" : [{"add": {"accountId":"{{lookupTable.get(DigitalProducts)}}"}}]
   }
}

-----------------------------------------------------------

my log looks just perfect with the correct user ID in it (I substituted users true IDs by ################):

{ "update": { "customfield_xxxx2" : [{"add": {"accountId":"################"}}] } }, { "update": { "customfield_xxxx2" : [{"add": {"accountId":"################"}}] } }, { "update": { "customfield_xxxx2" : [{"add": {"accountId":"################"}}] } }

However the assignment on the issue is inconsistent, sometimes is correct according with log other times it is not!! What's going on? This is annoying as I invested a lot of time and this would be a key feature to have on my project, support would be highly appreciated!!

Kindest regards,

[Bill Sheboy · Accepted solution]

Hi @Tomas Franco 

What are you observing in the audit log details that appears to be inconsistent?

If you write the branch variable, {{DigitalProducts}} to the log, does it contain what you expected?

Have you noticed any patterns to the inconsistency?  For example, the issue edits work as expected but the issue creates do not?

Kind regards,
Bill

[Tomas Franco]

Hi @Bill Sheboy  thank you for taking the time to look into this :)

The logs were looking just write, maybe it has something to do with making 3 requests in a row to add (in the branch loop) the users to the field. Or maybe some issue with how jira processes the "add" in the schema for the multi-user selection.

However I found a workaround. I will share it here for someone else in the future in case it helps.

Instead of using branch I just used string substitution, and using a support spread sheet I come up with a long statement to define a variable Users 

Users = {{customfield_xxxx1.value.replaceAll("App1","User_ID_for_APP1").value.replaceAll("App2","User_ID_for_APP2").value.replaceAll("App3","User_ID_for_APP3")}}

As we have 40 apps you can imagine this is quite long but with a support excel sheet it is manageable. In this manner I was able to add all desired users in a shot, by editing the issue with:

{"update": { "customfield_xxxx2": [{{#Users.split(",")}}{"add": {"id":"{{. }}"}}{{^last}},{{/}}{{/}}]}}

Now one additional important thing to notice, is that what is retrieved by the smartvalue {{fieldChange.tostring}} varies depending whether the rule is running on creation or status transition (which is annoying), I guess it can be solved with an If Statement.

Do you know how can I ask if the trigger is on creation or transition?

[Bill Sheboy]

Interesting...based on what you describe, and again without seeing your rule, I suspect the branch's parallel processing was causing the symptom.

Regarding detecting the trigger type, you may try the {{eventType}} smart value to infer that: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/#--eventType--

However, please note the smart value {{fieldChange}} is only available for triggers where a field change is involved.  It is not available for issue create.