How to get a String value from a multipicker user field in Jira Cloud using JMWE

[Alexander Nezis]

I am working on rebuilding some workflows from Server to Cloud, using JMWE post functions. We have a service desk form that uses an approver multi picker field (Software Owner Approver) to set approvers for various software requests.

In Server, I set this field to a specific account so when that approver is set, a transition occurs (move to To Do in our case).

Here is the syntax in Server:

issue.getAsString("Issue Type") == "Software Request" && issue.getAsString("Software Owner Approver") == "sdesk-serviceacct"

Essentially, issue transitions when this conditional statement is true. However, in Cloud, JMWE does not allow me to get the value of the multi-picker user field in string. This is how far I got:

{{
issue.fields["Issue Type"].name == "Software Request" and issue.fields["Software Owner Approver"].accountId == "accountId:6336fc4b3ac41ebde76cc7a4"

}}

What is the correct nunjucks syntax to run a conditional execution that returns true if the issue type value and the multi user pick value return true?

[David Fischer · Accepted solution]

Hi @Alexander Nezis 

The problem is that a multi user pocket field can contain more than one user. On Server, your test was checking whether the field contained a specific user, and only that user. Is that what you're trying to achieve on Cloud? If so, try this:

{{
issue.fields["Issue Type"].name == "Software Request" and issue.fields["Software Owner Approver"] | length == 1 and issue.fields["Software Owner Approver"] | first | field("accountId") == "accountId:6336fc4b3ac41ebde76cc7a4"
}}

[Alexander Nezis]

Hey David,

Thank you so much for the reply I will test this later today and follow back here!

Is it possible to use != for when I want the condition to not equal that account?

For example would this work?

{{
issue.fields["Issue Type"].name == "Software Request" and issue.fields["Software Owner Approver"] | length == 1 and issue.fields["Software Owner Approver"] | first | field("accountId") != "accountId:6336fc4b3ac41ebde76cc7a4"
}}

[Alexander Nezis]

Hey David,

I probably have something wrong on the setup still. On the create function, I have a Set Issue Fields post function that sets the Software Owner Approver to the user in I specified. 

I can test with the issue that the statement returns true. It also returns true for the post function that you gave me.

Here is how the workflow looks:

All those post functions are on the Create step. Essentially, when that Software Owner Approver equals to that account, it should take the transition from Create to To Do.

The Software Owner Approver is not in the screens for the issue. Could that affect this? We didn't have it in the screen setup in Server prior.

[David Fischer]

Can you share the list of post functions from the transition view?

If I understand correctly, you have two post functions on the Create transition, one that sets the Software Owner Approver field, then one that transitions the issue. In that case, you need to understand that post functions do not run in order in Jira Cloud. The only way to guarantee the execution order is to use a Sequence of Post Functions post function and put both existing post functions in it. 

[David Fischer]

As for your other question, yes, != works but be careful with your boolean logic - the code you wrote will also return false if the custom field is empty or contains two users. Is that what you want?

[Alexander Nezis]

Hey David,

Let me try the sequence of post functions first and get back to you. I didn't know Cloud does not follow the order.

As for my question, this should work. The Create step only assigns the user ID I mentioned above, based on a condition. There would be no other user value assigned until the next transition occurs.

[Alexander Nezis]

Hey David,

Thank you so much for the solution. After incorporating both to our workflow, the requests are following the correct status based on the custom fields.

I appreciate your help on this as it completely solved our issue.