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.

Are you serious!? A ticket from 2004?

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"?

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

My suggestion is this....

Just like defining schemes associated to projects, we should be able to save CLONE schemes, which defines what get's cloned per project. The scheme could either clone without prompting the user, or per suggestions above, prompt for what fields to clone.

Use case....

We are proofing JIRA as a help desk ticket system. Most out of the box functionality works great except when we get many calls about the same problem (ie, an important system is down) - We call these "major incidents" and need to quickly tie many callers (reporter) to the same issue. The best way to accomplish this is to clone the first call and then have to manually change the reporter to the caller. However, this is is a "memory item" manual step and prone to error. We really need to be able to clone and specify the reporter in the same operation.

Vote!

<<< Include Watchers >>>
It would also be great to decide if the watchers are taken over into to the clone!

We would love to see this implemented as well. We are currently running JIRA 3.12.3 Enterprise with a commercial license.

We would also like the ability to change values (summary, affects version in particular) on the subtasks before the clone operation is saved. This way we won't have emails sent out with the wrong information. I realize that this will require some type of wizard similar to the one used for Bulk Move functionality.

At a minimum, it would be great if there were an option to not send email following the clone. If there was a new Clone Issue notifcation event created we could configure this event to not end email after a clone.

Adding a vote for Polycom. We would like to see this feature in JIRA. An extended 'clone' feature should provide the ability to select whether to copy attachments, comments and even change history.

My preference would be something like a list of checkbox options to Clone.

<p>Include
<ul>
<li>Subtasks
<li>Comments
<li>Worklog
<li>Workflow Status
<li>Attachments
<li>User defined fields
</ul>

I'm not sure if anyone mentioned this so I'll chime in.

Email notifications are sent before the issue has been updated because of this issue.

For example, on our setup emails are sent when issues are created. When issues are cloned this is what happens.
1) User finds an issue they want to clone.
2) They hit the clone button. The small dialog appears and they set a new summary. (Instead the user should simply be brought to a new issue screen with all the existing data populated.)
3) The user hits the button to continue. << The issue is created and the notification is sent BEFORE any other changes are made. The issue can not be updated before the notification is delivered.

I agree strongly with this. It's a right PitA that clone doesn't actually do the complete job. I'd settle for it copying everything (without options not to), and I can manually get rid of the stuff I don't want from the cloned issue.

Any news about this issue ?
It will be very usefull if we can choose the fields we want to clone, and also the customs fields.
Many thanks

Hi,

Thanks for your feedback. We will certainly take your comments into account when considering this issue.

Thanks,
Brian

For me, it´s essential to specify the status of the clone. I don´t want the clones to be "open" automatically. We like to clone issues that have to be tested in 32bit as well as 64bit environments when they arrive in the test departments responsibility. Those issues have a status like "To be tested" and I want them to go on with this status.

Maybe it´s easiest to allow a choice between the clone as it is now and "Clone everything".

It would also be delightful to clone an issue INTO ANOTHER PROJECT.

Right now that is one of our most time consuming annoyances with JIRA. We sometimes have the same issue affecting different clients (sometimes with very subtle differences that can be differentiated by a single field change or comment after having cloned the original issue) but right now we have the chore of creating a new issue in a different project and copying & pasting field by field content and then manually adding the link to the original issue.

The options to clone sub tasks and issue links will be available in JIRA 3.6. See linked issues JRA-9649 and JRA-9650

I think the specification of the Clones' status while cloning is an useful feature.

It would be also great to be able to change workflow state when cloning.
I have workflow with "closed" state as finite without ability to reopen by anyone. This state was "accepted as is" let me say during acceptance tests.
Within this model cloned issue is put in the same "closed" state without ability to push things forward.

As a default, I'd say that any field that is required ought to be cloned. This is not currently the case.

My preference would be something like a list of checkbox options to Clone.

IE.

• Include Subtasks
• Include Comments
• Include Worklog

Hi,

What would you prefer to be the default behaviour?

On JRA-4821, the suggestion was made to have checkboxes for the different parts of an issue to be cloned.