cloned sub-tasks do not receive the original sub-task's status

[Eric Jahn]

When I clone sub-tasks within an automation, the cloned sub-task workflow status reverts to the beginning workflow status.  In my case this is the "To-do".  It does not receive the same status of the sub-task it was copied from (such as "Completed").

A possibly similar (slightly different, with more complex pre-conditions)  issue: https://community.atlassian.com/t5/Jira-Content-Archive-questions/Cloned-Sub-task-not-copying-proper-Status/qaq-p/2233327#M306309

[Ste Wright]

Hi @Eric Jahn 

You can extend your rule to copy the Status from the issue being cloned (assuming it's the trigger issue).

You will need to ensure however it's possible to transition from the creation status (eg. To Do) to the target status (eg. In Progress) directly.

The relevant rule details would look like this...

• Action: Clone Issue
• Branch: Related Issues
  • Type = Most recently created issue
    • Branch-Action: Transition Issue
      • Destination Status = Copy from trigger issue

Ste

[Eric Jahn]

But does this work for cloned sub-tasks.  I use the method you describe for other issue types, but it is not available for cloned sub-tasks (only issues).

[Ste Wright]

Hi @Eric Jahn 

Yes, it should do.

Could you show us the wider rule you're trying to incorporate the transition into?

Ste

[Luka Hummel - codefortynine]

Hi @Eric Jahn

I'm Luka from codefortynine 👋

This happens because cloning in Jira creates a new issue with the default status of its workflow, rather than directly copying the status of the original issue.

To address this, you could consider a two-step process in your automation:

1. Clone the Sub-task: First, clone the sub-task as you're currently doing. This will create a new sub-task with the default workflow status.
2. Update the Status: After the cloning, add another step in your automation to transition the status of the cloned sub-task to match that of the original sub-task. This step will typically use a transition action in your automation rule. It's important to ensure that your workflow allows for this transition, which might mean you need to add additional transitions to your workflow to accommodate this.

However, managing these kinds of complex workflows can sometimes be tricky within Jira's native functionality. If you want to try a third-party app for cloning, our Deep Clone for Jira can clone issues, and sub-tasks and even bulk clone while maintaining certain aspects of the original issues, like links, attachments, and statuses.

Remember, it's also essential to ensure your Jira workflows are configured to allow the necessary transitions.

[Nic Brough -Adaptavist-]

Hi Eric,

This is because "clone" creates a new issue.  As it's a separate item to the original issue, Jira has to assume it is new, and hence take it through the workflow as intended.  It can not know that you want to start a new issue part-way through your process.

[Eric Jahn]

Yes, that's Jira's interpretation of a clone.  But then how do I go about actually syncing the state (specifically the status) from the original issue? Synced data is what most would consider actual cloning (deep-copy versus shallow-copy). It's been suggested I do this in a separate step, but how does this separate step access the original issues' sub-tasks' statuses? This is what @Luka Hummel - codefortynine is keying in on above, and whose response I will be looking into, and following up on.