JSM Automation - Cloned and Linked ticket not copying custom list selection (multiple choices)

[jsprockett]

Hi,

I have created a JSM cloud automation that clones and links a new JSM ticket to a Jira ticket. In the Create work item section, I have updated each of the 'Choose fields.....' with smart values that correspond to the field or custom field.

The issue I am experiencing is one custom field that is a Select List (multiple choices).

• I initially used the smart value for the custom field {{issue.customfield.12689}}, and it works if only one choice is selected in the JSM ticket.
  • If I select multiple choices, the cloned Jira ticket will show 'none'.
• I have tried {{issue.Environment.value}} and {{issue.customfield.12689.value}} and neither of them work for multiple selections.

I need the ability to choose multiple selections and have them cloned to the new Jira ticket.

I appreciate any help or guidance with this issue. Thank you

[Bill Sheboy · Accepted solution]

Hi @jsprockett -- Welcome to the Atlassian Community!

First thing, your rule is using the Issue (Work Item) Created trigger.  That one can start the rule before all of the data is ready for use.  The mitigation / fix for that is to always add the Re-fetch Issue (Work Item) Data action immediately after the trigger.  That will slow the rule a bit and reload the data before the steps proceed.

Next, rather using the smart value that way to set the field, please try this:

• in the Create new work item action, for the field, select the ... menu at the right side, select COPY, and then select to copy your field from the trigger issue
• if that does not work, you will need to use a JSON expression to set the values: https://support.atlassian.com/cloud-automation/docs/advanced-field-editing-using-json/#Multi-select-custom-field

Kind regards, 
Bill

[jsprockett]

Hi @Bill Sheboy

Adding the delay and moving the field to Copy worked like a charm. Thank you for the guidance.

Take care, JT

[jsprockett]

Hi @John Funk and @Bill Sheboy

Here is the final working copy.

I added a 'Then: Re-fetch work item data' and set the field to Copy.

[John Funk]

Great - thanks for sharing!

[Mikael Sandberg]

Hi @jsprockett

Welcome to Atlassian Community!

In order to set multi-select fields you have to use advanced field editing option that you will find under More options in the Edit work item component. You can either user the option value or the id like this:

{  
  "update": {
    "customfield_12345": [{
      "add": { 
        "value": "option 1"
      },
      { 
        "id": "12345"
      }
    }]
  }
}

 Check out this KB for more information on what you can do with the advanced editing option.

[jsprockett]

Thank you, @Mikael Sandberg

I appreciate the immediate reply and assistance.

Take care, JT

[John Funk]

Hi @jsprockett  - Welcome to the Atlassian Community!

You should be using {{triggerIssue.xxx for al of those and not {{issue.xxx

[Bill Sheboy]

Hi @John Funk 

FYI...at that point in the rule, both {{issue}} and {{triggerIssue}} refer to the same thing.

Kind regards,
Bill

[jsprockett]

Thank you, @John Funk and @Bill Sheboy .

Unfortunately, neither trigger nor issue works for this issue.

I appreciate the immediate reply and guidance.

Take care, JT

[John Funk]

@Bill Sheboy  - Why is that? The trigger is based on creating a work item, then he is creating a second work item, so how can they be the same?  And your guidance was to change it to copy from the trigger work item. I am confused. 

Hey @jsprockett  - can you post your final working copy rule for others that will come see this? Thanks!

[Bill Sheboy]

Hi @John Funk 

The {{triggerIssue}} smart value (when it applies) is constant throughout a rule and the {{issue}} smart value is based on context.  Please consider this example rule below:

trigger: work item created	At this point, {{triggerIssue}} and {{issue}} refer to the same issue.
action: some action	Still the same.
branch: some branch to other issues	Still the same.
action: some action inside the branch	Inside the branch, they are different, where {{issue}} now refers to the branched-to issue(s).
action: some action after the branch	After the branch, they are once again the same issue.

Regarding the use of the COPY from the trigger issue, I believe the original intent was to copy from the trigger issue.

The original rule's problem was using the smart value directly to set the field converted it to plain text, but when there are multiple values they produced a text string that could never match a selection value, such as "A, B, C" rather than a list of values.  Using COPY preserves the typing of list -> list.

The other possible workaround would be using advanced edit with JSON to make the list management more explicit.  (This is normally required for the fields not yet in the action's field dropdown list.)

[John Funk]

Gotcha, I am so used to there being a branch, I overlooked that or even just assumed it in my thinking. Thanks for the clarification and this would make a great article to be published!