Hi everyone,
I am looking to use automation to create a rule that when an issue is created via Request Type it will {{LookupIssues}} based on certain criteria and depending on that lookup it will then need to either create a sub-task in the existing issue or create a new parent task. Whether this is possible I am unsure...
However, when I say {{issue.parent}} it does not seem to look for only the parent issues and seems to come back with all the issues and same occurs when I try with {{issue.parent.resolution.Unresolved}}. We would need to use multiple JQL lookup's and from what I have seen the suggestion is to create variables.
Please if some guidance can be given it will be appreciated!
Thank you!
Hi @Robynne Barnard and welcome to the community!
Can you please provide a little more context on this? Specifically...
Hi @Mark Segall ,
The JQL I am trying to look for is the parent issue, as well as the resolution.
And correct Request Type does relate to JSM, but for our purposes we require sub-tasks as issue types in our projects. Hence, we have added them and they are working well.
In terms of the rule:
Trigger: Create issue
Conditions: Request Type = XX or Issue Type = XX
Actions: Lookup issues and create an issue
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for the additional clarity, but I'm still not fully following the architecture. I understand using sub-tasks with requests. However, what I'm trying to understand is where this comes into play in your rule. Let me pose a hypothetical:
New request has been generated from the portal. This triggers the rule, but the request type has no parent or child issue at this stage. It's simply an orphan request type. How is the rule expected to identify a parent/child issue from here?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
So, that is what we are trying to figure out. We would ideally want it to identify the parent issue based on an Asset Field and a parent issue that is in resolution open.
Ideally the request is created in the portal and then we would want it to look for an issue that matches an Object in an open parent issue and create a sub-task within that parent task if it finds one.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ok - This is clearing up for me. Thank you for being patient with my line of questioning. So, I have one more:
A new request has been created. What is meant by "parent"? Are you putting your requests into Epics or are you creating some type of logical link to another issue that simply plays the role?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Not a problem. It has been a bit of a confusion for myself too.
No Epics used that I know of.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
So, what are you meaning by "parent" as it relates to a request?
...depending on that lookup it will then need to either create a sub-task in the existing issue or create a new parent task
This is where I'm still not clear on your question.
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.
Thanks, but I'm still trying to put this together as I'm still stuck on your meaning for that part of the question I quoted above.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Essentially we want the lookup issues to return whether there are any existing 'parent issues'/ requests that have that particular Asset Field in it. And if it does not find anything matching that field then it would need to create a new request/ parent issue.
I hope this makes sense. I am a bit new to it all still.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ok - I'm getting a better understanding now (thanks for your continued patience), but I think what's had me hung up is that you should never run into not finding the parent issues situation because sub-tasks cannot be created without having a parent.
Let's walk it through with clearly defined steps in a process:
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.
Great. So in that case, you'll want something like this:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Good morning @Mark Segall ,
I gave it a try and it is progress. The error it gives me is that it either does not exist or I do not have permission to view it. This is how I have set it up. Maybe you can see any errors I have made?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Your Lookup query needs a tweak. Try this:
cf[10923] IN ({{issue.customField_10923}}) AND issueType != Sub-Task
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Mark Segall so it ran successfully, but it did not find "parent issue" and create a sub-task in that related parent issue sadly.
I will keep trying though
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Can you please share a screenshot of the audit log for the rule? This will help me get better understanding of what's happening vs your expectation.
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.
Ok - So in this instance it found no matching issues. If this is an expected outcome, you'll want to update your ELSE condition to include whatever you want to have happen which is where I'm still not 100% sure I understand. You'll want to add the appropriate action as a component under that Else condition:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
What is happening is that when I create the issue in the portal. I want it to look for is the customfield outlined in other parent issues and if there are parent issues that already exist with the specified customfield it must create a sub-task in that issue.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If nothing is found we want to trigger a new request to create a new parent task based on the customfield.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Got it - I think this filled in the last thing that I was fuzzy on. So, to make sure I'm on the same page:
You have at least 3 issue types in play for any given asset:
If I'm understanding this correctly, you'll just need to add a new ACTION: Create Issue under the Else condition. In that create issue action:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Mark Segall ,
Thank you for all the assistance. Sadly, still no luck. It keeps rendering the error that it cannot find the Asset custom field. Will keep trying, but may explore other avenues as well.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hmm... Maybe try using = instead of IN...
cf[10923] = {{issue.customfield_10923}} and issueType != Sub-Task
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Mark Segall , I hope you are well.
Sorry for the delayed feedback.
I have managed to refine the automation and it is looking up the exact parent issue I am looking for now.
However, it i creating the sub-task in the newly created parent issue which is created from the request. I thought perhaps I could use a move action to move the sub-task to the issue that resulted from the lookup issue portion? However there is no action at present that allows you to move an issue in automation.
I thought maybe I can try and use Advanced fields.
Please see attached. So essentially we want to move BORROW-317 to be a sub-task in BORROW-150 and not create a whole separate sub-task.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes - You need to change the parent in the advanced portion of the Edit Issue:
{
"fields": {
"parent": {"key":"{{lookupIssues.key}}"
}
}
}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Mark Segall ,
Slowly, but surely, making progress. I have the following issues when adding the above to advanced fields.
Any ideas on how to go about it? Not sure what the error means exactly.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That message means that the syntax is right, but the link is breaking the Jira hierarchy (e.g. making a task a child of another task). Can you please confirm that when you say, "Sub-Task" that you actually mean the "Sub-Task" issue type?
If it is any issue type other than sub-task, this approach won't work and instead we'll need to look into some type of linking strategy to create a logical parent/child relationship rather than one that is enforced (which is how the Parent field works)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Mark Segall ,
Yes, we created a sub-task issue type named Borrow (ST). Do you think this will cause an issue?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hmm... That shouldn't be a problem, but perhaps its trying to set itself as a child of another issue type that is a sub-task issue type category?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
So the issue that we looked up in the first part of the automation is what we want to 'move' the sub-task to. And that issue is a Parent issue that is why I am a bit perplexed. Maybe I just need to play around with it a little more... It is getting close and I just need that one missing piece and it will slide into place - I HOPE!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hmm... I know changing the sub-task parent should work because I've tested it successfully in my personal environment.
Can you please share a screenshot of the Edit Issue action so I can make sure everything looks ok?
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.
Thanks for sharing... I see the issue now.
You won't be able to convert an issue to a sub-task. As a workaround, you could do this...
Delete the Edit Issue component from your rule and replace with this:
This will clone the issue and link it to the trigger issue and close out the trigger issue.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Mark Segall Yay!!! It worked!! AMAZING! Would it be possible to rather delete the trigger issue instead of just closing it? And then delete the link?
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.
There is definitely a Delete Issue action if you want to go that route. My personal preference is to not delete due to its destructive nature.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Mark Segall Let me try it with ways and see which works best. We just want to avoid duplication and risk of things being done twice. Thank you so much for your help and patience!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Mark Segall , I hope you are well.
I seemed to have hit another snag with my automation.
After the lookup condition I am trying to get the automation to create a NEW Request if there was no results rendered in the lookup, but that renders errors and does not create anything.
I tried adding it into the "Else" section but still no success do you have any suggestions? I cannot even seem to create sub-tasks beneath that. I have tried branches, I have tried pretty much all I can think of and thought maybe you would have a suggestion. Thanks in advance.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Can you please share the screen shot of the error entry in the audit log and a look at the create issue action you're trying to employ?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
So it will create an issue in this instance, but I have set it that it deletes the issue for the lookup as we have a cloned sub-task, as we set last week.
So if I do not delete it then it causes duplication with the lookup automation, but then causes chaos when a new issue needs to be created and no lookup is found.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'm not quite sure I understand all of the components under the Else condition. You should only need to have the Create Issue action under the Else condition. The error is indicating that you're trying to create an issue type that is a sub-task but not providing a parent key. I believe the parent should simply be set to the trigger issue.
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.