Automation rule to create multiple subtask based on user picker (multiple users)

[Helen]

My issue has a "User Picker (multiple users)" called "Reviewers". I'd like to write an automation rule to create a subtask for each user in Reviewers and set that user as the assignee.

I have written a manually triggered rule which works when there's only one person in the Reviewers field. However, I need to be able to iterate over each user I think, and I can't work out how to do that.

Any suggestions for Jira Data Center would be gratefully received.

[Bill Sheboy · Accepted solution]

Hi @Helen 

Unfortunately, Jira Data Center does not have the Advanced Branching over smart values feature as that would make this easy.  Here is the suggestion to add that feature, which you may watch / vote for to see progress: https://jira.atlassian.com/browse/JIRAAUTOSERVER-749

There are at least two workarounds using automation rules:

#1) Use the REST API bulk-issue create endpoint

• Using smart values and list iteration, build a JSON expression to bulk-create the subtasks, storing the JSON with Create Variable 
• Call the bulk-issue create endpoint using the Send Web Request action 

In my opinion, this is the better approach as it is less likely to fail due to rule looping.

#2) Use a recursive rule with the Incoming Webhook trigger

• With your current rule, gather the user information, and use the Send Web Request action to "call" another rule, passing the user data and parent issue's key
• Create a second rule with the Incoming Webhook trigger 
  • In this rule, receive the data for the users and parent's key
  • Branch to that parent with JQL on the key, adding the subtask with an assignee
  • Remove the user from the list, and
  • Check if there are any remaining users to process
  • If so, call the rule recursively with Send Web Request with the remaining users

This two-rule approach is susceptible to multiple possible failure points, and so the #1 approach is better.

Kind regards,
Bill

[Helen]

Thanks Bill, the option of a bulk create via the REST API hadn't occurred to me. That seems like a good option - definitely more robust than the recursive rule. I'll give it a try.

[Helen]

Just thought I'd add a more detailed implementation of Bill's answer...

Create a smart variable named tempA containing the JSON e.g.

{
"issueUpdates": [

  {{#issue.Reviewers}}
    {
      "fields": {
        "project": { "id" : "10500"" },
        "summary": "Review the document",
        "issuetype": { "id" : "10004" },
        "parent" : { "id" : "issueKey" },
        "assignee" : { "name" : "{{.}}" }
      }
    }{{^last}},{{/}}
  {{/}}
]
}

The resulting JSON will contain an entry to create one subtask for each person in the Reviewers field. In order to get it to work though, I had to put placeholder text for the issue key link back to the parent, I couldn't just substitute in {{issue.key}}. Not sure why probably to do with scoping the issue fields.

Instead I used the following statement to do the substitution, adding it to the custom data section of the REST API call:

{{tempA.replace("issueKey", issue.key)}}

I actually substitute multiple values here, chaining the replace calls together.

Thanks Bill, I couldn't have done this without your help!

[Bill Sheboy]

Well done, @Helen !!

FYI -- The reason the issue key was not visible is a long-standing limitation / defect of long-format list iteration: once inside the iterator, only data from that scope or lower is visible.  Your workaround with the replace() function is quite helpful for this case. 

Another workaround (when more fields are needed) is building a delimited list of fields using inline iteration and text concatenation, and then using the long-format iteration and text functions to parse them.  For example:

{
  "issueUpdates": [
    {{#issue.Reviewers.concat(":").concat(issue.key).join(",").split(",")}}
      {
        "fields": {
          "project": { "id" : "10500"" },
          "summary": "Review the document",
          "issuetype": { "id" : "10004" },
          "parent" : { "id" : {{substringAfter(":").asJsonString}} },
          "assignee" : { "name" : {{substringBefore(":").asJsonString}} }
        }
      }{{^last}},{{/}}
    {{/}}
  ]
}

That smart value dynamically builds a list using inline iteration, formatted like this:

Alice:ABC-123,Bob:ABC-123,Eve:ABC-123,Mallory:ABC-123 

And then immediately splits it back into a list for long-format iteration, later using text functions to access the Reviewer and Key values, adding the asJsonString function so they are wrapped with quotation marks.

That will definitely work with Jira Cloud, but I do not know if it does for Server / Data Center as it relies upon the list item {{.}} being the implied parameter to the substring functions.  If you want to try it, I recommend storing the entire JSON in a variable first to confirm it fully evaluates before use in the Send Web Request action.

And...if any of the Reviewer names contain comma or colon characters, the delimiters would need adjustments :^)

[Helen]

That's fascinating Bill, thanks for the tip! I don't do enough with these sort of things to really know all the ins and outs.

[Nacho Moreno Ortega]

Hi @Helen ,

I am Nacho and i am part of Decadis.

You can achieve the desired behavior by using our app Jira Workflow Toolbox as mentioned by Christos.

To do so, a JWT automation rule can be created with the following configuration:

Expression from the issue details in which "NNNNN" must be modified for the id of the Reviewers custom field.

toStringList(%{trigger.issue.cfNNNNN})

You can easily decide when these subtasks will be created, for example when a field is updated or a transition is completed.

It is also possible to add a condition or validator to restrict the issue creation depending on your needs.

If you need any kind of assistance in the creation, please do not hesitate to contact us via our Support portal .

Best regards,

Nacho

[Christos Markoulatos]

Hi @Helen 

it should work on DC also. just copy the smart value to the assignee

[Bill Sheboy]

Hi @Christos Markoulatos 

The Advanced Branch is not supported for Jira Server or Data Center automation, and thus this approach will not work.  Here is the suggestion to add the feature:

https://jira.atlassian.com/browse/JIRAAUTOSERVER-749

Kind regards,
Bill

[Christos Markoulatos]

Hey @Bill Sheboy you are absolutely right, correct be if im wrong but u can achieve the branching functionality with JWT or JMWE if u have these 3rd party apps in DC.

[Bill Sheboy]

No doubt there may be marketplace apps to fill that need for Data Center, and I was describing above how to do it with the built-in features...until that branch is added for DC (which seems unlikely given the upcoming sunset of DC support).