I heartily endorse this feature request. 

Up for this problem. 

I noticed quite a few comments from the early stages, but I'm curious—has there been any progress since then? Or is it already wrapped up? +1

19 years and counting.  +1

Only 19-year old suggestion. I will just give it a vote. Might not help to dust it off but you should never give up hope.

Hey dac3a3fc0734

How is this bug Invalid? JRACLOUD-80788

We've raised a support ticket and the support explained the reason. It's because the property "jira.permission.createclone.denied" was never used in Cloud 🤷‍♂️ The list of Cloud properties is here:
[Use workflow properties | Atlassian Support|https://support.atlassian.com/jira-cloud-administration/docs/use-workflow-properties/]
They'll update the bug too.
And this Suggestion is for bringing this feature (to disable cloning) back.

https://getsupport.atlassian.com/browse/CES-42030

Right!

How is this bug Invalid?   JRACLOUD-80788 

Could anyone explain why this Bug is invalid?

How is this bug Invalid?  JRACLOUD-80788 

It says it's resolved in  KEN-487. How is this resolved?

This feature is gathering interest for 19 years, do we wait another 19 years for it to be implemented?

dac3a3fc0734 we used Jira Cloud Automation to clear all of epic fields and get rid of cloned by link when an epic is cloned. For required epic fields (such as Summary) that cannot be cleared / be blank, we put placeholders such as [PLEASE UPDATE SUMMARY]

The fact that you cannot control what can be cloned or not was already bad, but there was this property solution. When you have automations in place, cloning can easily ruin your flow. Identifying what is a clone or not is a headache.

So, because of the related bug, now people don’t have any option to create stories faster in the same epic, they always need to use the Create button and fill in the parent. Quite disappointing.

Is there any other workaround to control what can be cloned or not?

I need this feature too... there is a lot of "non technical" users that clones issues and they do not clean or reset important fields such Fix Versions, Components, etc. 

I can confirm that the workaround works for us in our Jira Cloud environment. However, when we disable cloning of epics it also disables the ability for users to create child issues under epics (you can only create sub-tasks under epics if the workaround is applied). So, for us the workaround doesn't work from the process perspective, since our users need to be able to create child issues under epics.

There is a bug JRACLOUD-80788 opened regarding this issue. If you ran into to the similar problem, I suggest you vote for it and add yourself as a watcher.

I tried implementing the workaround for a workflow and it's still allowing me to clone. Can anyone confirm they got the workaround to work in Jira Cloud?

This is from 2005. If this ticket was a human child, it would be turning 18 this year!! Yay!!

Seriously?? A clone permission is a very basic feature. In my projects, I have people cloning tickets that have tons of rules and processes, so cloning creates tickets that are screwed up from day 1. Things that are irreversible, actually.

There's a reason why cloning humans is not a thing. Tickets should be the same!

Now, this ticket being sitting here for 18 years is SOOOO SHAMEFUL! Especially because there are other permissions that are missing as well. This is not the only one - for instance, the permission to create fix versions. I have to give my scrum masters admin power simply because of this.

Atlassian, helloooo? There are users here on the other side...

Try out Enhanced Links for Jira  to customize Issue Link Types per (Project ,Issue type or other criteria) using JQL expressions .

Enhanced Links for Jira allow you also to :

• Bulk Update Issue Link Types .
• Bulk Delete Linked Issues via bulk change .

There are some more useful features like :

• Edit Jira Linked issue fields in list view.
• Enable coloring for Jira issue link types .
• And more ...

Stay tuned : New feature will be launched soon : Control visibility, display order, and usage for Issue links.

Documentation ! Questions? Ask us any time , or send us an E-Mail to support@atlassway.com  and we will get back to you as soon as possible .

I love it when I find these decade plus old issues for requests for feature parity with the on-prem product without any response from Atlassian.  I've commented on a number of these over time.  

How about we get a response from someone at Atlassian before this one hits 19 years old?  That's almost 3 months away.  

https://getsupport.atlassian.com/browse/JST-887742

Related, in a manner of speaking: JRACLOUD-80110

Our team would like to see this feature added as well. It would definitely make things easier for admins.

It happens very often that what the company producing the software sees as a feature can actually be a defect or a road block to others. It's all about having different perspectives, Atlassian!

Cloning is helpful, of course! We can all make use of that ability! But we also need the ability to control what can be cloned, when, who, etc.

So for me, there's no doubt this is a must-have... Cloning tickets can potentially ruin with the entire logic. of your processes.

We also find that users will often times clone tickets because they are too lazy to enter with information over again, but by doing that they oversee important steps and information that must be provided in the natural flow. On top of that, add impacts as far as workflow decisions, automations, validations, etc. which can certainly lead to multiple mistakes.

Again, when Atlassian thought of this feature, it should've also provided users with the ability to configure it. That's the presumption that comes from not having other perspectives and feedback from other people outside of product. And that's when software companies fail all the time!

Apologies for any confusion caused - The following was posted here by mistake.
I believe this issue is a duplicate of JRACLOUD-16325 – Customise Issue Links per project

I recommend that watchers of this issue vote on and watch the above issue. So that votes aren't split, I believe this ticket should be closed, but I will wait a week before taking any action in case anyone thinks both issues should continue to exist. Thank you!

Since we are using

Deep Clone for Jira (Cloud)

https://marketplace.atlassian.com/apps/1218652/deep-clone-for-jira?tab=overview&hosting=cloud

we need to be able to disable the standard clone.

Hi,

I think that would be useful too.

Users are cloning issues way too often..

The suggested solution is excellent.

Cheers,
JG

Simplify the work and usage of Jira issues if clone issues is controlled by admins! 

Admin should able to disable clone!
Add a Clone Issues permission to Permission Schemes.

uncontrolled cloning is a pain. please give admins the powers they need to deal with unexpected poor decisions by users who don't know what they are doing.

for my organization cloning means duplication of many custom fields that need to be blanked out - which makes Jira useless for data collection of those fields: The data can't be trusted because you can't tell what is there due to a clone that could not be prevented or enforced and what was properly filled out by a user.

Hi Robert, 

Good luck getting this backlog cleaned up, or looked at.  My company had a ticket that the support team looked at and addressed.  I gave them the specific keys in this backlog that were the same item so they could mark them as resolved also.  The response I got was: different product managers care for different areas of the product, and so they choose how/when to update this backlog...  That might explain why there are 10+ year old suggestions and defects in the backlog.

On the plus side: when server version begins sunset activities in Feb 2021 (completing in 2024), maybe all of those open items will be marked as Closed/Will Not Resolve.  ;^)

Best regards,

Bill

This issue is duplicated by several other issues.  Can someone at Atlassian take some time to consolidate these into a single issue or at least one for CLOUD and one for SERVER. Currently this request goes back to 2009 and having duplicates dilutes the votes.

I would add that splitting feature request between server and cloud does not seemt to make any sense. I understand that occasionally this makes a difference in implementing a solution but when gathering interest for a new feature this differentiation does not matter. Plus all CLOUD features work in SERVER it's only in the other direction that there is some feature gaps due to security. When a feature is implemented in SERVER and not CLOUD then you can clone the SERVER feature issue and mark it as will not implement.

Here are the ones I found with a few minutes of searching there may be others.

https://jira.atlassian.com/browse/JRACLOUD-36494
https://jira.atlassian.com/browse/JRASERVER-36494

https://jira.atlassian.com/browse/JRASERVER-16325
https://jira.atlassian.com/browse/JRACLOUD-16325

https://jira.atlassian.com/browse/JRACLOUD-8497
https://jira.atlassian.com/browse/JRASERVER-8497

https://jira.atlassian.com/browse/JRACLOUD-59123
https://jira.atlassian.com/browse/JRASERVER-59123

https://jira.atlassian.com/browse/JRACLOUD-42181
https://jira.atlassian.com/browse/JRASERVER-42181

WARNING WARNING WARNING

Implementing the workaround will also prevent the "Split" function to work. If you want to disable "Clone" but you still want to keep "Split" like in my case, this workaround doesn't work.

Jira should be customize to handle project better way. Admin should able to disable clone, it is very annoying for organisation to pileup the issues.

Much needed feature. Please implement.

Thanks

We need to disable "clone" feature by project by project basis. Please implement this feature. 

For info: existing [ScriptRunner|https://marketplace.atlassian.com/plugins/com.onresolve.jira.groovy.groovyrunner] customers can now hide system or plugin UI elements. This allows 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.

regards, Mark

Is this easily switched on/off by Admin now without code needed? Please can someone update to clarify. - Thanks

We also need to disable this feature for certain roles / groups. I would vote for it but for some reason my account does not allow it. The problem with this feature is that Cloning a defect will copy all fields and some of them are only valid at certain points in the workflow. Users are Cloning in an attempt to create a new defect and they do not have the permission to change all of the data in all of the fields in the cloned issue. This leaves us with an invalid cloned issue. Please fix this!

this works for me in Jira 6.0.x

<div class="footer-body">
<script type="text/javascript">
jQuery(document).ready(function($) {
    if($('#project-name-val').text() == 'BI Request'){
        $('#clone-issue').hide();
    }
});
</script> 

Please reopen the issue, it wasn't fixed. There was just an workaround but it is not working anymore.

Not work in Jira 6.0

To remove the Clone Issue menu item in JIRA 4+, just add a Velocity Processed Message custom field and put it on the screens where you want the clone option removed for users. No server file edits needed. Set the field's Default Value to:

<script type="text/javascript">
{
cloneMenuItem = document.getElementById('clone-issue');

// hide the Clone menu item
if (cloneMenuItem)

}
</script>

Since this is a Velocity processed field, you can get fancier about who is allowed to see Clone Issue w/ addn Velocity markup that makes the Javascript conditional based on the current user's group membership, project role, or whatever.

Tyler, you can change the text of the message (e.g. to "Clone complete.") by following instructions on customizing text.

OK, so I see that deleting the clone link through the admin interface causes the link to not be created, but how do I keep this message from being shown to the users?

>> Note: The clone link type "Clone" does not exist. A link to the original issue will not be created.

This issue was resolved, but I don't see any solution for the original request (Neal's solution points to non-existent file in 3.13).

How can I keep JIRA from creating an automatic link to the cloned issue?

I don't want to limit users ability to clone, just not have the link, since feedback from users is that the link is meaningless.

Please open this issue back up, since I don't believe it has been resolved per the original request.

Anyone with an answer to this question, please comment - Thanks.

I noticed that now there is a clone plugin that allows you to have clone operational in JIRA or completely disabled.

What we are looking for, is an upgrade to JIRA (or that plugin) that allows the 'clone' option to be made available only to some Groups, individuals, projects, or screens.

For example, I might want developers in one project to be able to clone and move as needed (preferable in one step). However on another project I might only like the clone option to be there for any user submitting a topic, so they can clone their last submission, and not have to retype everything again, but instead just make minor changes to more quickly submit multiple different topics but with similar input fields due to the nature of the person's position and current goals, such as Tech Support, or a Q/A Engineer.

I hope this could be done by JIRA. Very useful feature, and an improvement on an existing feature. Thanks.

Can we have a "Clone" permission so that certain users (developers, power users9 can clone an issue but at the same time the "Clone" link is not visible to all other users with the "Create Issue" permission?

It is not quite a proper permission as the user could create a new issue and type in everything manually, making a manual clone. But it would help unclutter the left navigation bar.

To clarify, in 3.7 you can go to Administration -> Plugins, select "Issue Operations Plugin" and disable the "Clone this issue" module. The "Clone" link then disappears.

In JIRA 3.7, all issue operations are available as 'web links' which you will be able to enable or disable through the admin UI.

Tell me about it. See JRA-8102 (and the master issue JRA-5417).

To be able to CLONE and MOVE in a single operation would be very useful.

MOVE is very useful if the original project does not care about any traceability. But most often the original project CLONES the issue and then MOVES the clone, for example if a problem is found in a library that is managed in a different project.

Issue cloning is worthless to most of my users as they are not granted Move permission.
They have Create permission in both source and target projects, and cloning issues would be useful, but I want to restrict Move permission to a small group of users.
So either make it possible to hide the Cloning action, or preffered make Cloning a one step process with a separate permission.

David,

You could write a clone issue operations plugin that would only appear for certain groups, but you won't be able to configure it very easily

Cheers

Mark C

I've edited the JSP for now, but will wait for 3.5.

Will the plugin allow access to this link per group? Just curious - I don't think anyone would really use the Clone Issue link.

The operations can now be plugin-nable (is that even a word). So we should be able to break it into plugins so people can show / hide things a bit easier.

You can remove the link if you're willing to edit the .jsp source.
http://forums.atlassian.com/thread.jspa?messageID=257219866&#257219866