Create New Issues For Each User in a Multi User Picker Field Through Automations

Tom Scoggin March 25, 2024

In one of my processes I have a multi-picket "Reviewer(s)" field. I'm trying to use a REST webhook to create a ticket for each person listed.

I was able to:

  • Add a comment to the ticket using the automation
  • Validate the webhook and see the users listed in the custom field of my test ticket

Now I'm stuck and can't find any good documentation on how to extract the users listed in the custom field and make new tickets.

Can someone help?

2 answers

1 accepted

0 votes
Answer accepted
Kalyan Sattaluri
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 25, 2024

Hello @Tom Scoggin 

Please share what you have currently implemented as I am having hard time understanding the ask, especially where you have added a comment but I dont see that as requirement initially and not sure where you have added that comment.

Please correct below statement:

You have an existing ticket with multiple reviewers selected, you want to create new tasks (sub-tasks?) for each of them and assign to them?

Tom Scoggin March 26, 2024

Good morning,

My comment about an existing ticket is just to state that I have a sample ticket I'm using to test out my automation. I'm trying to create a new Story issues for each of the Reviewers listed in that test ticket. I can't figure out how to pull the data from the returned REST call and then creat the tickets.

Begining of REST Call.PNG

Kalyan Sattaluri
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 26, 2024

Hello @Tom Scoggin 

Couple of things:

You dont need additional If condition after your scheduled trigger or a web request to get a list of reviewers.

You could give the same JQL in scheduled step itself and you can access the reviewers list directly using smart value.. {{issue.Reviewers}} 

But, more importantly, because you are in Data Center edition, you dont have Advanced Branching to do For /Each to create issues for every reviewer found. So this is a limitation/blocker for you.

If you have a limited set of "Reviewers" then you can hard code them in If statements, such as:

If {{issue.Reviewers}} contains "Bob" -> then create issue for Bob..

You can add multiple such conditions given you know the list of potential reviewers.

Please let me know if this approach works and I can share a simple screenshot for reference..

Also, I can broadly share how to read your web request response but as mentioned, that is not needed for your use case because that information is already available to you.

Tom Scoggin March 26, 2024

The list of reviewers is unknown so I can't do an If statement scenario.

I'm not sure how you can use the results of the smart value {{issues.Reviewers}} to create a set of new tickets. If that's something that can be done then I'm good with trying that. I just don't know how you would go about that. That's why I was trying to get the data from a REST call that brings them in. 

I look forward to your response.

Kalyan Sattaluri
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 26, 2024

I am sorry but as mentioned, Data Center has no "Advanced Branching" option which cloud version does. So, however you get the list of Reviewers, you cannot create issues for each reviewer.

I will update this post if I can think of any work around.

Like Bill Sheboy likes this
Kalyan Sattaluri
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 15, 2024

@Tom Scoggin 

Other than Bill's solution, (which I am also interested in implementing but havent had time yet), I am going to propose another approach since you  really seem to need it. :p

This other approach will require 2 rules to complete your requirement. 

  • Rule 1: Trigger = your normal scheduled rule.
  • Rule 2: Trigger = Incoming webhook Rule.

You start setting up rule #2 first (partially) because this rule gives you an URL you need in rule #1. Then you complete Rule #1 and then you come back to complete rule #2.

At a high level, we are going to recursively call Rule #2 until we create issues for each your list of reporters. Hard to explain but once your implement all the steps, hope fully it will be clearer for you.

So we start with setting up rule #2 (partially)

  • Trigger = Incoming webhook,    Dont need to change anything else on this screen.
  • Action = Log Action => {{webhookData}}

Thats it. Now go back to Trigger screen and copy the URL. You will need it in Rule #1.

Give this rule a name and publish.

 

Now we set up Rule #1:

NOTE: I am testing with "Additional Assignees" field in my test. You should replace this everywhere below with the actual field from your Jira instance. Maybe its customfield_11700, I dont know. So please change that accordingly.

  • Trigger = Scheduled with JQL = ABC-123 .. (give 1 sample issue key for test purposes.)
  • Action = Log Action => {{issue.Additional Assignees}}    <-- you are logging your reporters. Again change it to your actual field.
  • Action = Log Action => {{issue.Additional Assignees.size}}    <-- you are logging how many were selected.
  • Action = Send Web Request => 
    • Give URL from rule #2 you copied earlier
    • HTTP Method = POST
    • Webhook Body = Custom
    • Custom Data = Below JSON:
    • {
      "reporter": {{issue.Additional Assignees.name.asJsonStringArray}},
      "count": {{issue.Additional Assignees.size}}
      }

Basically we are sending list of users and their count to rule #2 here in the payload. reporter is formatted as array and count is a number. Thats it. This ends rule # 1. 

Now, We do sanity check and test the set up.

  • As mentioned, In Rule # 1, in Trigger, in JQL section, give an issue key where this multiuser field is populated with more than 1 user.
  • And click Run in Rule # 1. Then when it has run successfully,
  • when you look into Rule #2 audit log, it should show the payload we sent.

If you see this, we continue completing our Rule #2. If you dont see this, you need to stop and investigate. Maybe you need to tweak your customfield smart value. So if {{issue.customefield_11770}} does not work, try {{issue.customefield_11770.value}} 

Continue next only after you are seeing the payload properly in Rule 2 audit log.

----------

Completing Rule #2:

We continue where we left off earlier where we set up trigger and put in log statement. So our complete steps then are:

  • Trigger = Incoming webhook,    <-- Dont need to change anything else on this screen.
  • Action = Log Action => {{webhookData}}
  • if Condition -> Compare smart values => 
    • {{webhookData.count}} 
    • Greater Than
    • 0
  • Action = Log Action => {{webhookData.reporter.get(webhookData.count.minus(1))}}
  • Action = Create Issue (like you normally would) where above smart value gives you the reporter you can assign in your newly created issue.
  • Action - Send Web Request 
    • Give same URL of this rule.
    • HTTP Method = POST
    • Webhook Body = Custom
    • Custom Data = Below JSON:
    • {
      "reporter": {{webhookData.reporter.asJsonStringArray}},
      "count": {{#=}}{{webhookData.count}} -1{{/}}
      }

This completes your rule #2.

Explanation: In this Rule, we are looking at "count" value in payload.

If Count is > 0, we will create issue by choosing reporter.get(count) and once we have created it, we decrement the count and call the webhook again.

Screenshot of Rule #1

image.png

 

Screenshot of Rule #2

image.png

 

Screenshot of Audit Log of Rule #2

As you can see from Audit log, rule recursively calls itself until count = 0, when it then exits and completes the job.

image.png

 

 

IMPORTANT -

If you dont implement the If condition, you will go into infinite loop, if you see that Rule 2 is running for ever, stop the rule by disabling it!

You can send additional data elements over to Rule #2 in Payload as you need, maybe Trigger issue key, trigger issue comments etc. You can modify the JSON you are sending over and include it in Rule #2 so every issue has the data.

Please Implement and let me know if issues. Share Rule and audit log of both rules when sharing updates so I can review.

 

Kalyan Sattaluri
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 15, 2024

*duplicate*

Like Bill Sheboy likes this
Kalyan Sattaluri
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 15, 2024

Screenshot of Rule #1

image.png

Screenshot of Rule #2

image.png

Screenshot of Rule #2 Audit Log

image.png

Tom Scoggin April 16, 2024

@Kalyan Sattaluri 

Sorry I didn't see this yesterday. I was head down trying to get the other solution to work. Did this solution create 3 new tickets for you?

Kalyan Sattaluri
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 16, 2024

Yes, I wouldnt have written above thesis if I hadnt tried it...lol.

 

If you specify the project and issue type when creating issues, it does create. Please see scree shots:

 

Rule #2

image.png

 

Audit Log of Rule #2image.png

Tom Scoggin April 16, 2024

@Kalyan Sattaluri 

Thank you. I just got the first part (verification/test) to work and am moving on the the second half of your steps. Thank you for this. I'm really hoping I can get the rest to work. I will keep you posted.

 

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 16, 2024

I have not tried this webhook trigger approach, and...

I wonder if it is covered by the looping limit (i.e., maximum of 10 loops) and so could halt the rule, or if because the trigger is a webhook, it "breaks" the detection chain and so is not detectable that way, allowing for many more than 10 issues to be created.

Like # people like this
Kalyan Sattaluri
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 16, 2024

Thanks @Bill Sheboy for that link. I wasnt aware. Def seems like 10 is the limit. Uff.

Tom Scoggin April 16, 2024

@Kalyan Sattaluri 

Well some success. I can create tickets but I can't add any other fields form the original ticket to the created tickets. Well other than adding the reviewers as an assignee now. 

You can see here that I can pull other data from the ticket and add it to the log but if I try and add any of it to the Whenever I add anything to the Post it gives me an error 500.

 image.png

 

When I try to add any of these fields to the Post (like below) it just doesn't work. That's when I get an error 500. Any thoughts about why I can't pass any other fields along to the second automation? I tried with _ and without. I tried differrent fields. Didn't make a difference. The only success was to only use the first two lines of code.

 

image.png

Kalyan Sattaluri
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 16, 2024

You need to wrap string in quotes for valid JSON..

For example, if I wanted to pass trigger key, trigger description over to rule #2 as well, I would use below JSON. If JSON is not formatted correctly, it will give you 500 error..

 

{
"reporter": {{issue.Additional Assignees.name.asJsonStringArray}},
"count": {{issue.Additional Assignees.size}},
"issuekey" : "{{issue.key}}",
"description" : "{{issue.assignee}}"
}

Tom Scoggin April 16, 2024

@Kalyan Sattaluri 

Well I was wondering about that. I've been watching videos about Json and that's what they said. I just didn't put the smart values in the same relm as strings. 

It worked once I did that. Thank you for all the help.

Kalyan Sattaluri
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 16, 2024

Great news. Couple of things:

In your send web request action, there should be a check box which says, "Delay execution of subsequent rule actions until we've received a response for this webhook".. check that in both rules,, In your use case, it does not need to be checked, but doing so will help  slow down Jira's pace.. 

Also, as Bill has mentioned, depending on how your Jira instance is configured, it may work only for 10 reviewers selected. If more than 10 are selected, this rule will run and create 10 new issues but 11 onwards will be aborted.. so we still need to evaluate Bill's solution to see if we can implement that logic..

Cause as of now, the For/Each is not in Atlassian's radar to deliver for Data center. Thanks!

Tom Scoggin April 16, 2024

Yes, I saw his comment. The most I would have is maybe 5. Most of the time it's two or three different people. You just don't know who they will be.

I will check those boxes.

Thanks again for all the help. I learned a lot between all of my reasearch and then all you guys provided. 

You and Bill ROCK.

Like # people like this
Tom Scoggin April 17, 2024

@Kalyan Sattaluri  My system is only creating one ticket instead of two or three. Are you creating your tickets with a Post or Create Issue.

 

Kalyan Sattaluri
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 17, 2024

I used normal "Create action" to create issues. What is your audit log showing?

Tom Scoggin April 17, 2024

Rule 1 Log shows a count of 4

image.png

 

From Log 2

image.png

Kalyan Sattaluri
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 17, 2024

You have a typo.

Should be -> {{#=}}{{webhookData.count}} -1{{/}} 

Instead it is {{#=}}{{webhoodData.count}} -1{{/}} , which evaluates to -1 and is exiting the loop.

Update it in your log statement and also the last step where you are calling the same ruel again.

Tom Scoggin April 17, 2024

@Kalyan Sattaluri 

Well, a couple of things.

I missed the step of doing a Send web request at the end of the second automation. Hard to do a loop without that!!

Then because I was using a lot more data fields I had to customize that web request as shown below to capture and resend the data for the next ticket. 

image.png

But it looks like it's working now.

Like # people like this
0 votes
Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 26, 2024

Hi @Tom Scoggin 

I believe Jira Server / Data Center can bulk-create issues using the REST API functions.  If so, your rule could use list iteration over the values in the multiple-select user field to generate the JSON needed to add the issues, passing that to the Send Web Request action to call the function.

Kind regards,
Bill

Tom Scoggin March 27, 2024

Thanks @Bill Sheboy

This is my first attempt at using Web Requests. When I test my Send Web Request and give it a ticket number it returns the correct information. I'm not familiure with List Iteration. Where is that?

I think the smart value I will need is to create the new tickets is {{webhookResponse.customfield_10192.username}}. This is the response for Reviewer(s).

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 27, 2024

Here is the documentation examples of iterating over lists: https://confluence.atlassian.com/automation/jira-smart-values-lists-993924868.html#Jirasmartvalueslists-examplesExamples

 

For your rule, you would iterate over the field values, adding the necessary JSON to create the issue.  Example pseudocode of that would be:

{{#issue.yourCustomField}}

JSON to add the issue...referencing the user values when needed, such as {{name}}, {{emailAddress}}, etc.

{{/}}

 

I am using Jira Cloud, but I believe this is the reference for bulk adding issues with the REST API: https://docs.atlassian.com/software/jira/docs/api/REST/8.7.1/#api/2/issue-createIssues

Tom Scoggin April 11, 2024

@Bill Sheboy  I'm back working on this. I was able to create a Webhook and then get a list of Reviewer(s) and add them in the Audit Log. I'm trying now to create Story tickets. 

I'm assuming I do it using the Create Issue plugin and then add my json under the Additional fields section.

I'm using this in the Create Issue Summary field - Review {{webhookResponses.body.fields.summary}}

 

When I try it now it's saying invalid json. Here is the code I'm using in the Additional fields section

 

{{#issue.customfield_10192}}
[
{
"fields": {
"customfield_11700": "{{webhookResponse.body.fields.customfield_11700.value}}"
"issuelinks": [
{
"type": {
"id": "10003"
},
"inwardIssue": {
"key": "{{webhookResponses.body.fields.issuelinks.inwardIssues.key}}"
},
}
],
"assignee" : {
"key" : "{{webhookResponses.body.fields.assignee.key}}"
},
"issuetype" : {
"id" : "10001"
},
"customfield_10101": "{{webhookResponses.body.fields.customfield_10101}}",
"creator" : {
"key": "{{webhookResponses.body.fields.creator.key}}"
},
"reporter" : {
"key" : "{{webhookResponses.body.fields.reporter.key}}"
},
"customfield_11340": "{{webhookResponses.body.fields.customfield_11340}}",
"description": "*Definition of Done:*\r\n\r\nThe assigned Reviewer has reviewed """{{webhookResponses.body.fields.summary}}""" and worked with the author to correct any concerns.",
"priority": "10000",
}
]
{{/}}

Tom Scoggin April 11, 2024

@Bill Sheboy 

Also this is what I'm using in the Add Audit Log and it works just fine.

{{webhookResponses.body.fields.get(0).customfield_10192.emailAddress}} {{webhookResponses.body.fields.get(0).customfield_10192.key}}

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 11, 2024

Tom, in the JSON you show there is:

  • a missing comma at the end of the line for customfield_11700
  • an extra comma after the "inwardIssue" section
  • an extra comma after the "priority" field definition

In my experience, the JSON parser for advanced edit does not like stray comments before closing curly brackets.  Please try updating those and re-test.

Tom Scoggin April 11, 2024

using this and still get "Error while parsing additional fields. Not valid JSON." I also have another version that was only saying that the project and issuetype were not set. Not sure if you want to see that one.

{{#issue.customfield_10192}}
[
{
"fields": {
"customfield_11700": "{{webhookResponse.body.fields.customfield_11700.value}}",
"issuelinks": [
{
"type": {
"id": "10003"
},
"inwardIssue": {
"key": "{{webhookResponses.body.fields.issuelinks.inwardIssues.key}}"
}
}
],
"assignee" : {
"key" : "{{webhookResponses.body.fields.assignee.key}}"
},
"issuetype" : {
"id" : "10001"
},
"customfield_10101": "{{webhookResponses.body.fields.customfield_10101}}",
"creator" : {
"key": "{{webhookResponses.body.fields.creator.key}}"
},
"reporter" : {
"key" : "{{webhookResponses.body.fields.reporter.key}}"
},
"customfield_11340": "{{webhookResponses.body.fields.customfield_11340}}",
"description": "*Definition of Done:*\r\n\r\nThe assigned Reviewer has reviewed """{{webhookResponses.body.fields.summary}}""" and worked with the author to correct any concerns.",
"priority": "10000"
}
]
{{/}}

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 11, 2024

Short version: my apologies, as I gave you an incorrect direction to solve this one.

 

You are using Jira Data Center, and that does not have an advanced branch feature for rules yet, as noted earlier by @Kalyan Sattaluri.  And...

Once inside of an iterator, no data from outside that scope is visible.  And so once the iterator starts for the {{issue.customfield_10192}}, no data from the {{webhookResponses}} will be visible.

 

At this time, the only ways I can think of to do this in a rule are:

  1. when there is a known, defined list of possible reviewers, use a list of if / else conditions to add them
  2. complicated use of variables to build the JSON dynamically using inline iteration

 

To clarify that second one, which I have not tested, the idea is:

  • identify the JSON needed to add one issue, noting where the value from the custom field selections would be used (if needed)
{
"update": {},
"fields": {
"project": {
"id": "1000"
},
"summary": "a summary",
"issuetype": {
"id": "10000"
},
"assignee": {
"name": "value from custom field selection"
},
...
}
}
  • split that JSON into two parts: the part before the selection / user and the part after
  • store each part in a created variable, named varJsonPrefix and varJsonSuffix, respectively.  Ensure the suffix has an extra trailing comma at the end to handle multiple issue boundaries.
  • create a single JSON expression which spans all of the selected users in the field, using an in-line iterator and text functions, storing that in a variable named varIssueJson.  Please confirm the attribute for the custom field, as I am not using Jira Data Center.
{{issue.customfield_10192.name.join("~~").split("~~").replaceAll("(.+)",varJsonPrefix.concat("$1").concat(varJsonSuffix)).substringBeforeLast(",")}} 
  • How that works...
    • join together all of the selected users, with the known delimiter ~~
    • split them back apart into a list
    • use the replaceAll() function with a regular expression
    • to assemble the pieces together for the JSON
  • finally, add the wrapper JSON for the bulk add function
{
"issueUpdates": [
{{varIssueJson}}
]

}

 

UPDATE: After testing some of this logic, I changed the regular expression from zero-to-many to one-to-many to prevent empty entries after the split() function.

Tom Scoggin April 12, 2024

Wow @Bill Sheboy this is a lot for me. It will take me some time to work through this information. Like I said, this is my first go round with using rest api. It makes sence but it will take me some time to get it to work. OJT, LOL.

I will post here with additional questions as they come up.

Thank you for taking time to work this issue with me.

Like Bill Sheboy likes this
Tom Scoggin April 15, 2024

@Bill Sheboy 
Couldn't the varJsonPrefix and varJsonSuffix be combined into a single object and then in the varIssueJson only add the one object to the variable? Learning as I go. LOL 

First and second var is below. The "reporter" field needs to capture the user's key value from field customfield_10192.

var varJsonPrefix = {
"fields": {
"customfield_11700": {
"id" : "{{webhookResponses.body.fields.get(0).customfield_11700.id}}"
},
"project": {
"id": "12804"
},
"issuelinks": [
{
"type": {
"id": "10003"
},
"inwardIssue": {
"key": "{{triggerIssue.id}}"
}
}
],
"assignee" : {
"key" : "{{webhookResponses.body.fields.get(0).assignee.key}}"
},
"issuetype": {
"id": "10001"
},
"summary": "DCO Lead Systems Engineer Review of Service Asset Configuration Management Process"
}
};


var varJsonSuffix = {
"fields": {
"customfield_11340": "{{webhookResponses.body.fields.get(0).customfield_11340}}",
"description": "*Definition of Done:*\r\n\r\nThe assigned Reviewer has reviewed {{webhookResponses.body.fields.summary}} and worked with the author to correct any concerns."
},
};

 

var varIssueJson = {
{{issue.customfield_10192.name.join("~~").split("~~").replaceAll("(.+)",varJsonPrefix.concat("$1").concat(varJsonSuffix)).substringBeforeLast(",")}}

 

 

{
"issueUpdates": [
{{varIssueJson}}
]
}

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 15, 2024

I do not think so, and would recommend writing the constructed JSON to the audit log to check that approach prior to calling the REST API.

 

My suggestion was based on some assumptions...

  • there is a multiple select, user field
  • there is a need to create one issue per selection
  • with each value from the user field set to a field in the new issue (e.g., assignee)

If any of those assumptions are different, please let me know.

 

My suggestion was to split the JSON to the left / right of where the user value would be added to the JSON, allowing creation of a complete issue's JSON for each one.

Suggest an answer

Log in or Sign up to answer