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:
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?
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?
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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)
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.
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.
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:
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
Screenshot of Rule #2
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
*duplicate*
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Screenshot of Rule #1
Screenshot of Rule #2
Screenshot of Rule #2 Audit Log
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
Audit Log of Rule #2
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks @Bill Sheboy for that link. I wasnt aware. Def seems like 10 is the limit. Uff.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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}}"
}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I used normal "Create action" to create issues. What is your audit log showing?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Rule 1 Log shows a count of 4
From Log 2
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
But it looks like it's working now.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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",
}
]
{{/}}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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}}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Tom, in the JSON you show there is:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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"
}
]
{{/}}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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:
To clarify that second one, which I have not tested, the idea is:
{
"update": {},
"fields": {
"project": {
"id": "1000"
},
"summary": "a summary",
"issuetype": {
"id": "10000"
},
"assignee": {
"name": "value from custom field selection"
},
...
}
}
{{issue.customfield_10192.name.join("~~").split("~~").replaceAll("(.+)",varJsonPrefix.concat("$1").concat(varJsonSuffix)).substringBeforeLast(",")}}
{
"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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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}}
]
}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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...
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Kalyan Sattaluri - i have access to advance braching, and its working apart from i need to also assign the newly created tickt for each reviewer to the reviewer. how can i accomplish that?
Thanks
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
As this is a very old thread, please create a new question, perhaps adding a link back to this thread. That will ensure the maximum number of people see it to offer suggestions.
When you create your new question, remember to include the following:
Kind regards,
Bill
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.