Hi Jira Community,
I've been struggling to establish an automated rule that, by default, sets the parent of a cloned ticket to the same parent as the source ticket being cloned.
Here's where I've got to so far but any help/guidance would be appreciated.
Cheers!
I don't know if you managed to solve your use case with Automation but it's true that it can be sometimes rather complex to set up and afterwards, to maintain.
Our app Elements Copy & Sync was actually built to deal with this kind of use case: you can easily set up a configuration that clone a ticket, link it to its source issue and also share the same parent issue.
To do so, you have to create what we call a "Copy & Synchronize Jira work items" recipe and define from which space you're cloning, to which space and which fields should be cloned.
Make sure you add the parent field in the field mapping section:
You can try the app for free to see if it can help with your specific use case.
While you can achieve this with a Jira Automation, if this is a recurring process for sprint spillover or reusing similar requests, consider our app Deep Clone for Jira instead of maintaining a brittle automation rule. It is designed specifically for cloning work items, including more advanced scenarios and recurring clone setups.
With Deep Clone you can clone much more reliably than with a hand-built rule, and for larger hierarchies there is also Epic/Tree Clone, which is built to keep the hierarchical structure.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Stephen Anderson -- Welcome to the Atlassian Community!
First thing: what problem are you solving by cloning? That is, "why do this?" Knowing that may help the community offer better suggestions.
Next, what is not working as you expected? What does the audit log show when the rule runs?
Finally, for the rule you show...
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.
Hi @Bill Sheboy, thanks for the warm welcome and Happy Friday!
We want to reduce the amount of manual tweaking to tickets required when cloning, especially in Sprint planning, when cloning tickets that are spilling over. It's not a major time saving, but would make life easier.
In terms of what isn't working as expected, anytime a ticket is cloned - the parent mapping of the original ticket isn't replicated in the cloned ticket. The audit log shows it's running successfully which suggests I haven't got the logic correct.
Thanks for the guidance on re-fetch, I've added this in.
Here's a view of the end action - it appears to be set to the work item but it's not unlikely I've got this wrong!
Thanks again for your help.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for that information, @Stephen Anderson
Do you want to Clone the work item or edit a different one, as you now appear to be showing a different rule with different branching?
If you are branching to the Parent, select that field in the Clone action and then select "Work Item" for the value as it will refer to the branched-to item.
FYI -- When using the dropdown field selection in a Clone or Edit Work Item action, the same field cannot also be used in the "Additional fields". Please clear out that content.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Welcome to the community.
When will a cloned ticket be created, is this on a specific action in the source issue?
As based on the default Clone action if the original issue has a parent the cloned item will be linked to that parent.
So how do you clone an issue?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Marc -Devoteam- , thanks for the warm welcome and Happy Friday!
We primarily clone tickets manually when creating similar requests (to piggyback existing details) or handling spillover during Sprint Planning.
It's interesting to hear you say the default Clone action should link back to the original issues parent. This isn't happening in our current set-up - anytime a ticket is cloned, by default, the parent of the new ticket is set as blank.
Thanks again for your help.
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.