Here's another solution that doesn't require you to prepend the issue key to the Summary of the original issue and later parse it out. It simply uses an Incoming Webhook Trigger to create the Sub-task level children on the fly. :)
As with the original solution, this one uses two separate Automations:
The first Automation is Manually triggered. It simply Clones the Epic and it's direct children. As it's looping thru the children, it will fire off a Send Web Request Action to Clone the Sub-task level children (if any exist).
NOTE: Make sure the Header Key is set to "X-Automation-Webhook-Token" and the Value is the Secret found in the Trigger of the second Automation. The Web Request URL can be found in the Trigger of the second Automation as well.
The second Automation Rule uses an Incoming Webhook Trigger...
Thanks for this very helpful solution. I've been looking for a solution for a long time. I got it working, but I see one thing i need to fix. I hope someone can help me out.
I have a set of stories underneath my Epic. A few of these stories are linked to each other with "linked issues" option.
When I clone my Epic + all stories. The stories are all copied, but the "linked issue" shows a link to the source story. I need a link between the stories of the copied set.
Set of source stories: ID1 - Linked to ID2 ID2 - Linked to ID1
New set of copied stories (in my current automation): ID3 - Linked to ID2 ID4 - Linked to ID1
Wanted result: ID3 - Linked to ID4 ID4 - Linked to ID3
do you already got a solution for your problem regarding the linked issues? I would like to clone my template the same way like you but haven´t found a solution so far. Thanks in advance!
Thank you very much @Jorge H . I could successfully run Part 1 . But my Part B is not triggering at all. I checked all the values properly. Only difference is I am using Epic Link instead of Parent.
I was able to get both your solutions working in a project so thank you both!. My issue that led me here was trying to adapt it to clone an epic/story/subtask setup to a different project. I thought @Guy Anela solution with the webhook was the secret sauce but im still hung up. I am able to get the epic/stories to clone to the new project (building/running the automation from the templates project) for either method, but subtasks ive sat all weekend fighting with copilot and reading forums.
For giggles, I tried setting up the second part to listen in the destination project and used the webhook urls/tokens from the destination vs what it gave for the source but i get nothing in the audit logs aside from "config changes" to triage. I can see in the audit logs of part 1, the keys of the sub-tasks are claiming they are "passed"
If either of you would like to save the 4 hairs I have left on my noggin, I would greatly appreciate any help.
Hey @Timothy Roberts - If you post some screenshots of your Automations Rules, I'll try to take a look at them when I get some free time. Also, one thing you said stood out to me...
"For giggles, I tried setting up the second part to listen in the destination project ..."
You need to make sure that the Scope of both Automations Rules include the source Projects (where the items are being cloned from) and the target Projects (where the new items are being copied to). For grins, you can set both to "Global" just to make sure the problem isn't Scope related.
@Guy Anela a.) you rock! b.) I suspect your right in this may be related to scope. At least thats what I have been playing with the most trying to figure out. Few missing details for you:
~ We have 5 projects in play. All are TEAM MANAGED. One is dedicated for us to standup templates.
~ The Templates project is where both the epic/stories/subtasks all live as a the "source" we want to clone, as well as where I’ve stood up the automation.
~ I don’t have Jira God rights in our instance. Our Jira police don’t want to manage this type of thing assuming i were to have got it working as a global automation.
~ I did try running the same thing opposite over in the destination project and there I could see when co-pilot had me trying to use "lookup" style functions in the flow that the automation couldn’t find any work items from the simple JQL where as pasting the identical JQL in a filter showed them. So I figured it was scope related.
Attached is screenshot showing the details of each section of the flow for Part 1 and 2. Part 1 works and I get epic and its stories (in my case they are work types "Readiness" but think of it just like a story). I can even see where it is leaving behind your fix for injecting key:XXXXX in the "Readiness" work items name when it stands them up in the destination project. SO I believe the issue is in part2 just not able to see those items because its out of scope or some other reason.
Hi @Timothy Roberts - Just to confirm, are both PART 1 and PART 2 being executed within the same Project (e.g. PTAX)? If not, I would start with executing them within the same PTAX Project so you can confirm whether or not it's a Scope issue. You'll want to make sure that ALL of the items you're cloning (e.g. Epic, Stories, Tasks, Sub-tasks, etc.) ALL belong to the same PTAX Project as well (Again, for Scope reasons).
Hopefully this will at least get PART 2 to execute.
Also, based on your screenshots, it looks like both Rules are triggered Manually. When you execute PART 2, what item(s) are you executing it against? Is it the Readiness items that PART 1 creates? Please explain the execution process.
I would also add some "Log" action items to PART 2 to log the {{IssueOrigin}} smart value variables you're passing (just to make sure you're getting the values you're expecting). ...if you haven't done so already. :)
59 comments