Pls give us the oportunity to clone or copy the comments... 20ys issue

I wish I could add a *.gif to this feature request... there would be millions of funny memes on this one.

20 years an still no progress. Just close it and take the anger of the community with pride.

Yup 20 years is a bit long on a ticket. Upvotes on this one are way low. It's a good request I see no reason not to do it. Not having this wastes hours of my precious time looking for workarounds. Please implement.

Dear JRACLOUD-5052,

I know I’m a bit late, but I couldn’t skip wishing you a fantastic start to your 20s!

You’ve been wished for, dreamed of, and maybe even whispered about for two decades… and today, we are still waiting for you! 

Happy belated 20th birthday.

Here’s to maybe making a start on this request this year!

A key function for this request is the ability to deep clone from the issue hierarchy levels above Epic.

Curious why it takes Atlassian 20 years to determine interest. I think the interest is pretty clear and that Atlassian needs to get off your butt and get this done. This should be considered a basic feature functionality.

Hello !
I would like to know when this solution will be released in Jira, as I am having a problem with slow queues because I have to create two automations to supply one, as the clonings I do are not bringing the comments and I have to generate another automation to copy the comments, this way if this tool is inserted into Jira I will no longer have this second demand and this will speed up my internal company processes.

I would suggest that it be clear when cloning that deleting things in the clone will affect the original ticket. Also, functionality for copying (and not cloning) would be helpful to add. In this way, deleting parts of the copy (not clone) would not affect the original.

Please enable comments to be cloned whilst performing automation. Please also allow for projects as a whole to be cloned. 

Please, please, please make comments available on clones!  I'm pulling my hair out trying to get automations to work and stay working.

This is really annoying usability issue as the cloned reporter and assignee causes lots of Jira change notification mails and also information requests to wrong persons and others thinking that the ticket is to be done by the assignee. Manual updates are not always remembered to be done and extra manual step to e.g. clear the assignee or change the reporter is waist.

PLEASE!!!

Created:25/Oct/2004 11:31 PM  --> Am I reading it right? 

if yes, Today is 19th year anniversary of this Jira. Happy Birthday "JRACLOUD-5052"

https://getsupport.atlassian.com/browse/PCS-213174

Adding/removing watcher during clone automation will be very usefull.

Actually, as a workaround, I add watcher before cloning, and remove them after.... adding useless activity in ticket.

I have an automation rule that clones issues between projects and I was asked to also clone the comments.
Surely it can do that right...right? Nope. Suggestion open since 2004. Hilarious.

Fo the love of all - please please please - you can fill in fields when you create an issue, you can confirm them or update them when you move an issue, but we really need the option to double-check, modify, or delete old info from fields when cloning an issue!

It would be helpful if clone were also available as a bulk operation for multiple issues at once.

Hi

more I use Jira more I found limitations ;-(

I'm on Jira clous and when  I clone a Jira (having or NOT the modify reporter permission), the original reporter is kept, which is totally absurd !!!! I am the creator of the new Jira (created with clone option) but I also want to be the reporter. 

1. I made a test and this is the same result which is not what explained on different post I found

2. I do not get the reason of also cloning reporter field unless provoking some oversight of changing the reporter ?!?

Prices keep going up... this is one of the features my org actually needs.

Please bring this to Jira Cloud! So unfortunate to have to rely on plugins for this.

This will never happen.... a complete waste of time!

Still waiting... We definitely need to be able to copy attachments from one issue to another when cloning

You can use Clone Plus for Jira Cloud to copy attachments, watchers, comments, links, subtasks, subtask estimates, parent versions, epic issues, and their subtasks. I'm the product manager for the app. Let me know if you have any questions!

Voted for this!

If even over 200 votes is not enough to get this done, how serious do you take your busines and your customers...!? Being able to select the items that you want to exclude/include when cloning an issue is such a basic requirement that even the two minutes I spend on it here explaining it, is actually too much... Just get it done. Thanks.

give option to exclude Jira fields like Fix Version, Affected Version, Sub-tasks, Assignee, Reporter etc.

It would also be useful to clone from a customer support project in Service Desk into a sister development project in Jira Software

For Jira cloud, there is now a marketplace add-on called Deep Clone for Jira that allows to clone issues with embedded content.

Disclaimer: I'm the product manager of this add-on.

Try out our plugin, it has support for versatile cloning options including the possibility to carry over estimates or not
https://marketplace.atlassian.com/plugins/com.lbcg.jira.plugin.pro.BulkClonePro/server/reviews

We are also looking for the ability to clone tickets without carrying over the estimates. We run one week sprints and testing begins only after the sprint has completed and the next one has started. We are using the clone feature to create a new ticket (with minimal effort) when a ticket has a new requirement or has a new defect. We only use 'Reopen' when the ticket is still active in the current sprint. During our sprint planning, we are doing our best to review tickets that have been cloned so we can blank out the estimate. This allows room for error and this is why I support adding the functionality described in the ticket (https://jira.atlassian.com/browse/JRA-5052)

For info: existing [ScriptRunner|https://marketplace.atlassian.com/plugins/com.onresolve.jira.groovy.groovyrunner] customers can now hide system or plugin UI elements. This gives JIRA admins the ability to conditionally disable many JIRA menu buttons/actions including the Clone operation.

For full details, please go to our [Hide UI Element section|https://scriptrunner.adaptavist.com/latest/jira/fragments/HideUIElement.html] in the documentation.

The Clone operation could be replaced with a custom UI button (or buttons) to help Create a Constrained Issue with specific predefined fields like those mentioned in the description:

• Clone entire issue (subtasks, comments, worklog, everything)
• Clone with subtasks only
• Clone without subtasks

regards, Mark.

Additionally it should be able to select, if the cloned ticket should be integrated in the running sprint (as this spoils the burn down completely) or moved to backlog (which is mainly the preferred option).
And per default it must be able to set a assignee (currently the base assignee will be assigned in the clone -> unneeded mails are sent).

To pile onto earlier comments:

• When cloning, it should bring up a screen with all cloned fields populated, giving the user initiating the clone the ability to change fields before save. This will keep assignees/reporters/watchers from receiving an avalanche of e-mails when the user clones, then modifies a ton of fields to fit the current scenario.
• If we can't have the option to modify everything before a cloned issue is 'saved', triggering e-mail notifications, then we should have a new permission added, which only allows cloning to those with the permission. Too many folks attempt to clone tickets without really understanding the impact (e-mail avalanche).

Hi everyone,

Thanks for voting and commenting on this issue. Your feedback is key to helping us understand how you use JIRA so we can continue improving your experience. We have reviewed this issue over the last few days.

This suggestion is important for the JIRA development team, but we have not scheduled work and cannot provide an estimate on this. However, there is related work in progress, specifically JRA-7824 and GHS-6541.

I also encourage you to browse the Atlassian Marketplace for issue cloning add-ons. You might find add-ons that meet your requirements there.

Regards,
Daniel Franz
dfranz at atlassian dot com
Principal Product Manager, JIRA Platform

We have jusst launched a new plugin for this, compatible from 6.3.6
Check and evalutate on: https://marketplace.atlassian.com/plugins/com.lbcg.jira.plugin.pro.BulkClonePro
Best
Lars Broden

When an issue broke (invalid status), I cloned it and deleted the original. Unfortunately that deleted about a meter of user comments (Not that I like long comment threads, it's just that the users thought they contained useful info.)

Just a CLONE and MOVE in one operation would be enough for us so we can clone an issue into a different project (because those projects share some library code and therefore some bugs). It is very tedious and lots of extra spam when cloning and then moving in two operations.

It's a shame that all the issues representing specific clone operations desired are lumped into one issue and, if created separately, get marked as duplicate of this omnibus issue.

We just ran into the same type of issue reported in the "Laszlo Kremer 15/Jan/13 9:41 AM" comment. An issue that had a fix version was cloned, which caused the clone to never show up on our KanBan board. As this is using a simplified workflow I can't modify the create workflow to clear out the fixversion/s field.

We use very often the clone function to copy an issue to another, which automatically creates the link type "clone". But not always the link type is correct; hence we need to correct it afterwards. It would be helpful, if while we are cloning the issue, we could define, which link type should be used.

It is an interesting idea, but unfortunately it is not feasible.

The JIRA DB actually stores the Project ID (eg 10034 which implies "JRA") and the "Issue Number" (eg 1000), then glues these together at runtime (eg to make JRA-1000).

Furthermore you would break any number of issue key parsers in JIRA, plugins, and integrations in other applications (including the JIRA comment one as - you can see it getting confused with your JRA-1000-2 example)

Is it feasible for the clones to have a key that is created from the original key plus another digit or suffix. For example, issue 1 is JRA-1000. Clone it 3 times and the clones are JRA-1000-1, JRA-1000-2, JRA-1000-3. Is this feasible?

We would like to get a cloned issue without cloning the fix version of a release, bacause usually the clone issue must not be in the same release (fix version) as the cloned (mother) issue.

Please concentrate on finishing what you've done halfway such as this (Clone does not include comments etc.) and fixing bugs (such as incremental sync of jira-users group not working with MS AD) in your roadmap! Adding more bugs can wait until the old ones are fixed =)

We need this. It makes no sense to me, if we are cloning tickets, that we need to manually check off to also clone links, attachments, etc. If cloning, shouldn't everything be selected by default?

Hey Atlassian,

Having a separate permission for clone would be awesome.

The default setting of the GH Kanban board hides all issue which have a fixversion. It is really easy to clone a previously "released" issue, and it will not show up on the kanban board.

Please create a separate permission in the permission scheme.

Both comments and watchers are supported options.

Thanks for the plugin. But seems like this plugin does not allow cloning comments and watchers. If not watchers, atleast comments are must.

JIRA Clone Plus Plugin allows you to specify the list of custom fields to include/exclude. Administrator can configure this via a property file and provide different lists for different customized clone actions.

It would be nice to see a checkbox on the custom field configuration page to indicate if the custom field should be cloned or not.

Not having this feature causes serious bugs in the JaM plugin where it copies the primary key of the bug tracked in Quality Center, causing 2 or more tickets to have the same bug id. Ultimately, it causes corruption in the Quality Center database where 2 or more JIRA tickets try to sync to the same Quality Center ticket.

JIRA Clone Plus Plugin is now available! Please watch the video and vote for this plugin!.

it will be very useful to select what are all fields to be cloned
we are getting number of request for this to implement.

thanks

Christoph Enzinger has the right idea above. I would be nice to have an additional check box not part of the list for "Make this my default", so it will remember your selections.

It would be nice to reflect the name of the component under "Issue links/ Cloners" section of an issue where clone issues
come from different component.

Please give your suggestion on the improvement.

Thank you.

Clone should only clone fields that are on the Create Issue Screen.
We have many fields that don't get set on an issue until they are resolved.
When an issue is cloned, it doesn't make sense that the new issue is Open yet has all its resolution related data set.

We clone multiple sub-task under one master issue. While cloning, "Watchers" list is lost. This is extremally inconvinient. Can you provide the choice combo box for "Clone Watchers" as you did for "Clone Attachments"?

The ability to add watchers from a cloned ticket is a feature asked for by our users frequently.
Having this as a selection on a clone operation would be beneficial.

Hi Tyler,
While we're waiting for Atlassian..... the above functionality (ability to change Reporter during Clone) was developed for us as a plugin by CustomWare . Please contact them (e.g. founder Rob Castaneda) to see if they could extend the plugin for you.
Joanna/ Polycom