It seems to work with Jira server 7.13.3.

When cloning issue, just make sure option "Clone sprint value" is disabled. I thought it was an option for story points, but it isn't.

Please reopen this issue. It is still a problem in Jira v7.13.5 server version.

Reopen issue and please fix this for the Jira server version.

Please reopen and then resolve this issue for the Cloud version of Jira.  Cloning an issue which was in a prior sprint still copies the sprint information. 

Unlike other agile work management tools, there is no way to select/ignore which fields are cloned and the defaults to not seem to make sense.

Thank you for your prompt and relevant action!

Clone Plus does support excluding fields with a customized clone action - see How to exclude fields from being copied to the clone.

This Issue is a big joke. It as more than 5 year now! mjopson, Could you please check a look at it ? Thanks!

Dear Atlassian,

can this issue be reopened please. It is NOT fixed. Sprints are still being copied while cloning issues, which is very annoying. 

This feature was not available in JIRA server 7.2.3 and is still not there in 7.3 and 7.4 ff.

As stated by Jeremy this feature is mentioned in the release notes 7.2. But the issue JSWSEVER-6541 is somehow NOT on the list of "Resolved issues 7.2".

Atlassian, can you please verify why this issue is marked as "Fixed" although it has not been rolled out yet.

Thank you!

Thank you for your attention to this problem!  Clone is a valuable feature that is currently worthless due to this problem.  We were forced to disable it in our organization to prevent the problems this creates with historical sprint data.

I completely agree with Jeremy, this issue is not solved. There is no configuration option (at least not for version 7.3.8) and the only work-around is the post-function fix that requires an expensive add-on to be installed.

We are running JIRA server 7.3.7, and as far as we can tell this problem has not been resolved.

• There is no checkbox to not include sprint information when cloning an issue.
• The release notes say its fixed but offer no further explanation about how the new functionality works: https://confluence.atlassian.com/jirasoftware/jira-software-7-2-x-release-notes-826896227.html
• The only other (valid) information I could find about this was about using a post function on a transition to clear the sprint info, but it's not clear about what transition to use (the Create transition used to include create via the clone function; is there a new transition specifically for Clone?). https://confluence.atlassian.com/jirakb/clear-sprint-information-when-cloning-jira-issue-779159157.html 

This feature is now available in JIRA Software Cloud and JIRA Software Server 7.2.

Kind regards,
Martin
JIRA Software

I'm using v6.4.12 and it's not fixed here either, unfortunately. Will be watching for a fix!

It does not work in "Jira 6.3.15", please fix

regards,

radoslaw.antoniuk - major release in this case.

Kind regards,
Martin
JIRA Software

So as 7.1.4 was released on 6th April, this should be resolved? unless you mean stable = major release?

I cloned a story today as I needed all the sub-tasks to come to. Now all of a sudden I have this new story that is part of a previously closed sprint. A known "non bug" for 4 years - what a farce.

Has there been any update on a release date for this fix?

mattw678753797 - as noted above the fix for JIRA Software Server has not shipped yet, it will be in a forthcoming release.

Kind regards,
Martin
JIRA Software

This is still present in 7.0.2. can someone update the effects version? Also I noticed this is targeted for '2016-02-22 Cloud'. Would this fix be merged into any other versions?

my users will love JIRA again when this is implemented!!!

Awesome!
- A grateful scrum master

This feature is now available in JIRA Software Cloud. It will be available for JIRA Software Server in a forthcoming release.

Kind regards,
Martin
JIRA Software

When is this available for JIRA server?

Yay!

lena.nyberg - work is underway. Once complete and a fix version for the release is known we'll update this issue with further details.

Kind regards,
Martin
JIRA Software

I have just received a question about this from users and really look forward to the fix. Can you say anything about when you plan to launch it?

Can't wait to see this enhancement! Gotta keep those sprint reports pristine and sacred

There is a probably very controversial feature that you may want to implement on clone: (optional, with a checkbox) automatic adaptation of story points according to the work done, e.g. if 80% of the work is done, the story points of the issue could diminish accordingly. (But I am otherwise quite happy with the proposal above; thanks for priorizing this issue.)

kimwall - thanks for your comment. We will be addressing the Clone feature initially but will look to improve the Move feature in due course.
The related Move Suggestion is tracked by https://jira.atlassian.com/browse/GHS-10935

Kind regards,
Martin
JIRA Software

This is great news, Martin!

Any word on if this same checkbox will be added to the "Move" screens as that causes the same if not greater problems. I see that there's an issue related to that listed as a duplicate to this issue so my fingers are crossed that you're addressing it for that use case as well.

Thanks!

Thanks for commenting, voting and watching this Suggestion.

The JIRA Software team will soon begin work on this Suggestion. The proposed implementation adds a checkbox to the clone dialog, unchecked by default, to clone an issue's sprint value and will only appear for cases where the issue has a sprint value. This implementation is consistent with clone functionality for sub-tasks, attachments and issue links.

Kind regards,
Martin
JIRA Software

I used the script runner plugin https://marketplace.atlassian.com/plugins/com.onresolve.jira.groovy.groovyrunner/versions#b1426 to create the following Post Function on the Create Issue transition. It must run before the "Creates the issue originally" step

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.fields.CustomField
import com.atlassian.jira.issue.CustomFieldManager
import com.atlassian.jira.issue.*
import com.atlassian.jira.issue.link.IssueLinkManager

if (issue.key) {
    MutableIssue myIssue = issue
	CustomFieldManager customFieldManager = ComponentAccessor.getCustomFieldManager()
    CustomField sprint = customFieldManager.getCustomFieldObjects(issue).find {it.name == 'Sprint'}
    myIssue.setCustomFieldValue(sprint, null)
}

issue.key is empty on a new issue but is the old issue and key on a clone operation

Tested on Jira 6.4.10

Hope this works for others.

it is much easier to re-add a Sprint value, which actually does increase the scope of the Sprint. Rather than have ALL the accumulated values for the sprint from the prior issues, which had been moved from one to the next to the next and which values CANNOT be edited or removed.

This workaround has a downside. When creating a new issue directly into a sprint, the workaround also empties the fields, resulting the issue to show up in the backlog instead of the sprint. That confused our users, so this workaround is not helpful.

Your support site lists a Resolution, which is VERY helpful:
Utilize the post functions provided by JIRA Suite Utilities(JSU) to clear the values of the fields "Sprint" and "Story Points" on the Create Issue transition.
See here for details on Adding a post function: https://confluence.atlassian.com/display/JIRA/Advanced+workflow+configuration#Advancedworkflowconfiguration-addingapostfunctionAddingapostfunction

JIRA Suite Utilities is available on Atlassian Marketplace. https://marketplace.atlassian.com/plugins/com.googlecode.jira-suite-utilities

This issue should be solved. It's a real problem as the current cloning mechanism screws the burndown charts... (Cloned issue estimates suddenly appear in the current sprint.)

As others wrote above, this behaviour makes cloning unusable.

There is also a bug for this issue: GHS-10548 with a lot less votes than this one. The effort is set to XXL which seems a bit high.

I also voted for this issue to be resolved. Using a post-processing function to clean up after a clone is an ugly workaround, but not a fix.

Yes... this is utterly ridiculous.
Cloning at our company has become a great feature that cannot be used because when you clone it screws up the current sprint estimation
ATTLASSIAN... when will you fix this? 218 votes not enough??

It's really interesting to see the way Atlassian ignores real life problems.

I'm trying to restrict the team to drop stories in&out of Sprint by mistake and JIRA lets this simply by cloning an issue?.. How does "clone" mean include this item for an ongoing Sprint?... What is the logic behind this?...Unbelievable...

Wow, can't believe this is still an issue. I just had to go trough 15 workflows of various departments to add some post-function clear fields. Please automate this in the core software...

@Martin, with all due respect, I can not possible see how this would be desired behavior and any minority of users (opposite of your majority). When a user clones an issue, why would anyone look to retain this information? Why would they want to have duplicate issues in a Sprint? But specifically to the same point Karie made, it is a bug because you provide zero options to edit the information especially in the case of a closed sprint. This is where the problem lies and why it should be considered a bug.

Why not just add a checkbox to the 'clone' window below the "Summary" field that says: "Also clone Sprint". Default value is set in the JIRA Agile Configuration (Add-ons). So, companies that rely on the sprint being copied, can set it to checked and others set it to unchecked.
Can't be that hard to implement.

If you made it easier to edit and remove a closed sprint, then I think folks we be more tolerant. In other cases, when you clone, any information not wanted can be removed if the field exists on the edit screen. However, folks consider this a bug when the 'normal' process of editing doesn't work and the workaround, although listed, is not intuitive for the majority of users. Thus, reporting becomes inaccurate.

Why would a user believe that bulk editing to clear a field would work while editing to remove a value doesn't?

And, when you bulk edit, you have to clear all values - therefore, your sprint report becomes inaccurate as it appears you added, removed, and added and folks ask what caused the disruption to the sprint flow.

Thanks for watching this issue, I have updated the Current Status for above.

dorans, with regard to its classification as a Suggestion rather than a Bug, this is because the behaviour, whilst not desirable in many cases, is currently expected. There needs to be some consideration for the best way to solve this problem to cater for cases where the value is expected to remain and those where it should be removed.

Kind regards,
Martin
JIRA Agile

Is there a response from Atlassian that explains WHY this is a suggestion and not a bug? To me it clearly is a bug, I'd like to understand their point of view, as this bug is continuing to cause inefficient workarounds and headaches if employees do not follow the workaround. At this time, it seems more like a ploy to make their road map more convenient and less "problematic" than having substantial justification that they have a bug present in their system for X years.

Atlassian decided this isn't a bug when they changed it to a suggestion. So it will likely never get fixed. But even if it were a bug it might take six or seven years before they fix.

Take a look at this bug that is five years old and was changed to a suggestion: https://jira.atlassian.com/browse/JRA-23255

Here's a feature request that is going on 11 years old and has the top five most votes of all confluence features: https://jira.atlassian.com/browse/CONF-1732

We may be in for a long wait until this bug is fixed.

Hrmm, it's a bit odd that this bug fix is 3 years old? Any idea when it will get fixed? It regularly causes problems in our team.

@ahughes@thezenith.com that's a good point, thx

I read through comments and noticed @Brandon Fey suggested the same workaround and that it worked for others as well. My team doesn't usually add sprint at create, so they might be willing to live with the limitation.

When you have the post function on Create, anyone that is creating a issue from scratch (brand new issue). The Sprint information is purged as well. Users will have to add the sprint information after they create the issue.

I just added a post function to issues at the "Create" step in our workflow (will need to be done for each workflow/issue type the jira is cloned into) to purge some agile fields when users clone tickets. I haven't deployed to our active project yet, just a test project. Has anyone tried this approach already and seen any issues?

At least for our team, this is no longer a "Suggestion" or a just nice to have functionality, but a critical miss working of Jira with Agile. Issues are cloned through Jira, and all additional information resulting from Agile handling should be purged.

Hi Kevin, thank you for your comment, it is very helpful. Unfortunately some of the cloned issues had been moved to another project where the original owner had no rights to change the sprint. Therefore we had to ask the administrator of the other project to change the sprint information. This was no great pain because all projects are maintained internally in the company. But if the problem would be solved by Atlassian it would save us a lot of work (check issues, change issues,...). Therefore the ignorance of Atlassian is really annoying.

Hey Wolfgang. We have the same issue, and it has been frustrating for our users as well. Surprised it isn't getting more attention. This work around worked for us though.. Hopefully it helps you through.

• Performed a search for the desired issue in the issue navigator (for example project/task name)
• Clicked on Tools > Bulk Edit;
• Selected the issue and clicked "Next", then selected "Edit Issues" and clicked "Next";
• Selected "Change Sprint" and left the field empty;
• Clicked "Next" and proceed with the instructions to complete the change.