We'll begin working on a bulk clone feature in the coming weeks. We can update later on what the ETA will be as we learn more.
If anyone is keen to participate in early testing, can you drop me an email on eryan@atlassian.com?
Cheers,
Eoin
Product manager

Templates and automation are more complex than a simple clone functionality, which can be easily triggered and used. Why not implementing something that has so much demand after more than 10 years?

Below is already listed by another user above, But these are exactly same use cases we have:

• Library of requirements (or its subset) is cloned to the new project
• Library of tests or (its subset) is cloned to the new project
• Library of Tasks/Sub-tasks or (its subset) is cloned to the new project as the pattern of such tasks are similar across many projects with very minor differences.
• User wants to create dummy data for dry run / process correctness checking based on the real project data.

When we backport a fix to earlier versions of our product we clone one main Jira for all supported versions and we do this for up to 50 jiras per patch. The cloning work is exponential so instead of cloning once per issue we have to do it up to 4-8 times per issue.

What about this nonsense?

You can import from software to business project inside the same instance but not to another software project?!?

Oh my, my, functionality is already there, this is the clear sign Atlassian doens't  want to enable clone functionality for whatever reason.

Another basic functionality which we are waiting for years. 

If at least export and import would work as intended for wiki customfields, so we can retain formatting, no work from Atlassian wold be necessary. As of now, we still have broken import with no option to import tables or formatted text, and no bulk clone function. 

Or coveted templates functionality.

Hello ldeutsch,

I'm not sure how much you are really dealing and care about users' daily work issues. I commented based on what I see. And this the problem as developing companies take care about money and development/technical point of view but not about the real (bothering) issues.

I do not understand why there is an intention to complicate users life with automation. This automation must be build by somebody and managed somehow.

The request here is very simple:

Allow users to fully bulk clone selected the issues. Some use cases:

• Library of requirements (or its subset) is cloned to the new project
• Library of tests or (its subset) is cloned to the new project
• User wants to create dummy data for dry run / process correctness checking based on the real project data

Key here is the set that shall be cloned. With automation it's necessary to define input set, and it can be difficult. Instead to check issues in the list to be cloned is good. I'm not saying that automation cannot be used, I'm saying allow easy selection of issues to be cloned.

If you want to discuss more user issues, let me know we can meet Atlassian with the rest of our team to present the issues that we face. Some of them:

• not possible to have sandbox instance as 1:1 copy of production
• 3rd party plugins data are store out of Jira Cloud
• loading 3rd party plugins elements sometimes fails
• memory consumption of loaded pages is tremendous - in some case to load one tab consumes 1 GB o memory, opening more tabs makes JIRA/Browser unusable 
• Idera Inc. complaining about missing APIs to implement Xray functionalities properly

Hope that helped

Maybe templates would be more useful.  

We have a release process we repeat every release, and that will usually be a story with subtasks, which we need to clone every cycle.  If we could have a "template story with template subtasks" it could solve the issue.

From a lot of the comments in this thread, it looks like it would also solve their needs.

Hey 0ac814d1a7f9 and others with similar comments - my name is Liron and I'm from the product team at Jira. 

Our intent isn't to find 'justification' to build the use-case, as I've stated above we are looking to solve for repeatable tasks in Jira in the coming year. As with any product development process, we will want to ensure we are building the right solution and nailing the problem space, and that is what I was referring to when mentioning further conversations with users like yourselves which will help us validate our solution here once we start exploring the UX and design of the solution.

There is no mal intent, I can assure you, of anyone at Atlassian regarding this issue or others, and yes, we do care about user needs. I would be happy to jump on a call with anyone who would like to discuss this, or any other product issues further. 

Let me know and I'll send out a calendly link.

Cheers!

I'm not sure why it's necessary to again and again provide description and justification for obvious/common/basic use cases? Does Atlassian really care about user needs? Moreover when there is 1.5K+votes on this issue and the ticket is open for 10 years.

The only response is that there are paid plugins doing this basic operation.

Unfortunately, concretely the Deep Clone plugin that we are using, still faces problems to fully clone the Jira issues (e.g. Xray related issues) and who wants to pay for something what is working only partially...?!