Automation for Jira Rule JSON help

[Clark Everson]

I am trying to make a rule that if a user isn't in a group when a security level is set, the user is removed from the field. We are able to get it to remove all users, but not the specified user based off the user picker field (multi-select)

We don't want it to clear all because some of the users are actually in the group

The JSON I have for clearing all is:

{
"fields": {
"Additional Assignees": [{
"set": ""
}]
}
}

I am pretty sure I need something more like

{
"fields": {
"Additional Assignees": [{
"remove": ""
}]
}
}

but I can't figure out the removal criteria

I have also attached the rule via screenshots

[Darryl Lee]

It might also be useful to look at what the API shows you for the "Additional Assignees" field to see if it shows up as an array vs a scalar. As @Mykenna Cepek points out, if it's a scalar, you're not going to be able to use the remove verb.

So I just checked on my cloud instance, and the Approvers field, which is a multi-user field does appear to be an array.

Checked Required Participants over on a server instance of JSD, and it looks similar.

So it seems that on Server, where you can still use good old usernames, you ought to be able to do a:

{
   "fields": {
      "Additional Assignees": [{
        "remove": {"name": "username"}
        }]
    }
}

Maybe. :-}

Also, @Mykenna Cepek's recommendation to print the values to the audit log is also a good one. See what {{issue."Additional Assignees"}} returns, and that should guide you to trying to modify it.

[Aaron P_]

Hello everyone,
I know this topic is already old, but in case someone else can help and considering that after seeing all the documentation, all the comments about it and all the tests done using json, I only managed to add an individual user, when i put more than one user it just adds newest or gives error.

However there was a very simple way to do it that I tried and it is working correctly for me :)
You just have to create a variable and as a value add the Jira IDs of each user separated by commas, then you put that variable in the field you need and all the users are added.

In my case the field is called "Extra Assignees", a User Picker (multiple users) field, but the name doesn't matter ;)

In the image below, just change each IDJiraUserX to the actual ID of each user you have to add.

And then you just have to add this variable in the corresponding field:In case you retrieve them from a query via API or similar, instead you should put a foreach of the query in the value field:

{{#VarQueryName}}{{value}}{{/}}

This is so that it writes each value, if you see that it is not separated by commas add it after the {{value}}:

{{#VarQueryName}}{{value}}, {{/}} 

[Bill Sheboy]

Hi @Clark Everson 

To confirm your scenario:

• Additional Assignees users are set for an issue
• Later, the security level changes.  This security level is paired to a group of "authorized" people who can be set as additional assignees.
• When the security level changes, you want the Additional Assignee cleaned up so there are no unauthorized people in the field.

If that is correct, I don't think you can do this with Jira Server automation.

If this could work...I believe you could use the source smart value list of users, iteratively branch to build up a removal list, get the accountId values into a list, and use that to populate the "remove" line in the JSON expression...but I don't know how you are going to produce that list with Jira Server automation.

The Server version doesn't have advanced branching or created variables, and even if it did, branches of more than one value execute asynchronously.  So each update to the issue could walk-over prior issue updates.  You'd need something like an XOR or AND action between two lists to do this.

One challenge seems to be you are changing the security level after the additional assignees have already been set.  Have you thought if there is another way to change the order of steps and still achieve the goal?

Best regards,
Bill

[Bill Sheboy]

Hmmm...Perhaps you can do this this after all in Server with two rules and a custom field (e.g. UsersToCheck), although the approach seems a bit brittle to me...And, I have not tried this so I recommend experimenting in a test instance.

Rule 1: creates the starting condition to check the Additional Assignees

• trigger: on change to security level
• action: set the the custom field UsersToCheck to the current value of Additional Assignees

Rule 2: simulates recursion and uses the custom field UsersToCheck to "burn down" a semaphore value.  In the rule detail settings enable Allow Rule Trigger so this rule can lead to its own firing:

• trigger: the custom field UsersToCheck changes
• condition: the custom field UsersToCheck is not empty  <<< This is the stopping condition for the recursion!
• if/else condition: treating the custom field UsersToCheck as a list, check if the first value is missing from the security group
  • action: update Additional Assignees to remove the first value found in the custom field UsersToCheck
• action: update the custom field to remove the first value from the list, and so fire off the rule again

[Clark Everson]

Hi Bill,

You nailed it spot on what we are trying to do. I will test this!

Best,
Clark

[Mykenna Cepek]

Hopefully you've seen this documentation that relates:

https://support.atlassian.com/jira-software-cloud/docs/advanced-field-editing-json/#Advancedfieldediting-JSON--Addinglabels

I note that the Security list uses key/value pairs, and the set verb, whereas the a list of scalars like the Label field can use add and remove verbs as well.

For your use-case, I would experiment with the remove verb and the key/value pair you want removed.

A few other suggestions:

• Review the list operations available with Smart Value expressions
• Use the "Log Action" to dump (into the rule audit log) for confirming values at various times in your rule, to ensure they are what you think they should be, or to discover problem areas.