Automation to read multiple users from Assets and set them into Approvers field in issue

[Jorge]

Context:

We have an assets object type with an attribute (id:1445) Approvers which is of type users and can hold up to 2 names.

We built an automation rule to fetch these names and insert them into the issue Approvers field, taking the object value from the issue {{customfield_54102.key}}.

The component Edit issue fields works fine with the smart value as long as the Assets object contains 1 name, and then, the Approvers field in the issue is properly populated with the name.

Problem:

However, if the Assets object contains 2 names this approach does not work. The names are retrieved from Assets and logged properly, but the automation fail.

According to the documentation we tried Advanced Editing in may ways like:

{ "fields": { "Approvers": {{lookupAsset.attributeById.1445}} } }

or

{ "fields": { "Approvers": [ {{#lookupAsset.attributeById.1445}} { "accountId": "{{accountId}}" }{{^last}},{{/last}} {{/lookupAsset.attributeById.1445}} ] } }

Generally, these approaches provide a success in the automation, but the field in the issue still reamins empty.

I'm not able to understand the format comming from Assets. Is it a list of strings? a string representation of a list? How can I parse it to properly fill the Approvers field? Am I missing something else?

Regards

[Bill Sheboy]

Hi @Jorge -- Welcome to the Atlassian Community!

The symptom you are seeing is likely a timing, or racetrack, error in the rule:

• the Edit Issue action, when using JSON, can try to parse the JSON before it has been fully evaluated, and
• the looking up of the asset data takes time...regardless of how / where it is used in a rule

The solution for this is to force the asset data to be fully resolved before used in the dynamic JSON, by first storing it in a variable:

• action: create variable
  • name: varUsers
  • value: 

{{lookupAsset.attributeById.1445.join(",")}}

• action: Log the variable to check the values match what is expected
• action: edit issue, using the dynamic JSON expression

{
  "update": {
    "Approvers" : [
      {{varUsers.split(",")}}
        { "add": { "name": "{{.}}" } }  {{^last}},{{/}}
      {{/}}
    ]
  }
}

Kind regards,
Bill

[Jeroen Poismans]

Hi Bill,

Thanks for weighing in. The resolved JSON would be something like this, right:

{
 "update": {
   "Approvers" : [
     {
      "add": { "name": "userA" }
     },
     {
      "add": { "name": "userB" }
     }
   ]
 }
}

When I try this with hardcoded usernames (without the list iteration smartvalues), the error that OP describes remains. So not sure that the fetching is the issue here. Any thoughts on this?

Jeroen

[Jorge]

Hi Bill,

Thanks for the answer. Holding the value in a variable is a nice idea. After implementing your proposal I started getting the following error:

XAASP-3370 (Could not find usernames: a***k.j***t (customfield_50000))

After a search, I found this KB. The customfield_50000 (Approvers) is a user picker field. I tried to display the name in another variable with the format described in the KB note (just for log, not updating the field): 

{{#lookupAsset.attributeById.1445}}[~{{name}}]{{^last}},{{/}}{{/}}

or

[~{{lookupAsset.attributeById.1445.name}}]

I did this with 1 or 2 names coming from Assets. The first variable varUsers displays the content but it is not recognized by the content picker.

{
  "update": {
    "Approvers" : [
      {{#varUsers.split(",")}}
        { "add": { "name": "{{.}}" } } {{^last}},{{/}}
      {{/}}
    ]
  }
}

Could the simplified Edit Issue Fields component have an intermediate step under the hood to convert the user that I need to implement?

[Bill Sheboy]

Hi @Jeroen Poismans -- Yes, that is correct on the results of the dynamic JSON expression.  My understanding was Server / Data Center used the user name in this case.  Did you try that hardcoded example with Server / Data Center?

Hi @Jorge -- In the audit log you show, it appears there is a comma-followed-by-a-space delimiter between the names, and not a comma only.  That would then not work with the JSON expression I showed.

Please post an image of the action where you create the variable varUsers to help confirm that.  There may be extra spacing in the object attribute that needs to be removed with the trim() function.

[Jorge]

Hi Bill,

I tried any combination, believe me... :D

Regards

Jorge

[Jeroen Poismans]

Hi Bill,

Yes, have tried this on a Jira 9.12.18 with that result. It is indeed curious that it only occurs with multiple users + I have noticed something different.

My usernames were:

• jeroen.poismans
• JIRAUSERXXX

When using them separately (one approver), they both work using your update statement and JSON. When using both it is always the JIRAUSERXXX that goves the error. It suggest that maybe some lookup is happening behind the scenes, that doesn't finish as expected.

Jeroen

[Bill Sheboy]

Thanks for the follow-ups, and this does appear to be a defect (or a limitation in the REST API endpoint).  After a quick check of the public backlog, I did not find that symptom.

Another possible check: write the complete dynamic JSON to the audit log and then examine it for errors.

Also we can try a different workaround: adding them one by one using the iterator:

{
  {{#varUsers.split(",")}}
    "update": {
      "Approvers" : [
       { "add": { "name": "{{.}}" } }
      ]
    } {{^last}},{{/}}
  {{/}}
}

This will add an "update" section for each one.  Disclaimer: I have never tried this approach before with rule JSON.

[Jorge]

Hi Bill,

We discovered the reason why this whole thing is not working... It is a silly Crowd problem as the account IDs we are getting from Assets differ from the account IDs in the ticket (for the same user). When I get more information I will paste the whole working solution.

Regards

Jorge

[Jeroen Poismans]

Hi and welcome to the community!

The question is tagged with jira-cloud but the screenshots suggest that you are on server / datacenter. This is important to help you with your questions since the approach differs.

Can you confirm that you are not on Cloud?

Jeroen

[Jorge]

my mistake, corrected