If cells are cut and then pasted normally (i.e. with "Paste" instead of "Paste Special"), all formula links to these cells point to the new cell positions after pasting the cells. This shift of formula links does not occur with the command "Paste Special" after cutting cells. The result is unexpected: Formula links still point to the old positions of the moved cells. Therefore, "Cut" and "Paste Special" leads to the same result as "Copy" and "Paste Special" with subsequent deletion of the old cells. The expected and unexpected results are illustrated in the attached spreadsheet "Example-sheet-for-bug-report_Cut-and-paste-special-with-transposing_2013-10-30.ods" with the "Paste Special" option "Transpose". Instead of downloading the sheet, the following workflow can be carried out for illustration and reproduction. 1. Fill cell B6 with the number 4 and cell C6 with the number 7 2. Link cell E6 to cell B6 and link cell F6 to cell C6 3. Mark cells B6:C6 and cut these two cells 4. Select cell B7 5. Paste Special with selection "Paste all", option "Transpose", operation "None" and no shift of cells. Expected result: Cell E6 is linked with cell B7 and cell F6 is linked with cell B8. Actual result: Cell E6 is still linked with cell B6 and cell F6 is still linked with cell C6. I suggest the interim solution to disable "Paste Special" after cutting cells. Disabling "Paste Special" after cutting cells avoids potentially severe loss or change of data due to bug 68976. Disabling "Paste Special" after cutting cells does not lead to a loss of functionality. It can be replaced in the workflow by "Copy" and "Paste Special" with subsequent deletion of the old cells. A loss of functionality occurs only if this bug can be fixed by aligning the behaviour of "Paste Special" with "Paste" after cutting cells. MS Excel 2007 does not offer the full set of "Paste Special" options after cutting cells either. I do not have access to later Excel versions. I reproduced the unexpected behaviour under Windows 7 and Linux. I reproduced it with different LibreOffice versions including the most recent pre-release 4.1.3.2. I reproduced it with OpenOffice.org 3.3.0 as well. Hence it is inherited from OpenOffice.org.
Created attachment 88372 [details] Example sheet: Cut and paste special with transposing
Hi Raf, thanks for the issue. I can confirm it. But it's also related to setting Transposing on or not in my situation. Regards, Cor
I actually think the problem might be in “Cut+Paste”, not in “Cut+PasteSpecial”. The formulas in E6 and F6 should “follow” the new position of their “Precedents” if you *move* those precedents; e.i. select B6:C6 and *drag* the selection to B7:C7. But if you “Copy+Paste” or “Cut+Paste” or “Copy+PasteSpecial” or “Cut+PasteSpecial”, IMO the formulas in E6 and F6 should remain as they were before, pointing to the same “Precedent” cells, B6 and C6 respectively. I think that the respective behaviors should be confirmed with some other spreadsheet software of reference (like Excel for example) and then, perhaps, changed in LibreOffice accordingly.
(In reply to comment #2) > Hi Raf, > > thanks for the issue. I can confirm it. But it's also related to setting > Transposing on or not in my situation. > > Regards, > Cor Hi Cor, I double-checked and agree with you. The behaviour of "Cut" and "Paste Special" is only unexpected with the option "Transpose". Obviously I missed this point when writing the bug report. This fact implies that my suggested interim solution has disadvantages. Disabling "Paste Special" completely after cutting cells would disable expected behaviour as well. Alternatively, only the "Transpose" option in "Paste Special" could be disabled as interim solution. However, such a quick fix lacks charm admittedly. Maybe there is no convincing interim solution. Best regards, Ralf
(In reply to comment #3) > I actually think the problem might be in “Cut+Paste”, not in > “Cut+PasteSpecial”. > > The formulas in E6 and F6 should “follow” the new position of their > “Precedents” if you *move* those precedents; e.i. select B6:C6 and *drag* > the > selection to B7:C7. > > But if you “Copy+Paste” or “Cut+Paste” or “Copy+PasteSpecial” or > “Cut+PasteSpecial”, IMO the formulas in E6 and F6 should remain as they were > before, pointing to the same “Precedent” cells, B6 and C6 respectively. > > I think that the respective behaviors should be confirmed with some other > spreadsheet software of reference (like Excel for example) and then, > perhaps, > changed in LibreOffice accordingly. Hi Ady, I think that as well "Copy"/"Paste" as "Cut"/"Paste" behave well and as expected in LibreOffice. MS Excel does not behave differently. We agree that the links should not change after "Copy"/"Paste". However, I think that it is convenient that the links follow the cell in case of "Cut"/"Paste" like when "moving" or "dragging" the cells with the cursor. A large number of links can point to a single cell. If one wants to move this cell to another position in the spreadsheet without the mouse (e.g. to another worksheet), one can simply move the cell with "Cut"/"Paste". This workflow takes a few seconds also across worksheets, and the large number of links is adjusted accordingly without any effort. If "Cut"/"Paste" behaved like "Copy"/"Paste", the large number of links would have to adjusted manually. Best regards, Ralf
(In reply to comment #5) > If > "Cut"/"Paste" behaved like "Copy"/"Paste", the large number of links would > have to adjusted manually. Yes, Select+move works as Cut&Paste
(In reply to comment #4) > I double-checked and agree with you. The behaviour of "Cut" and "Paste > Special" is only unexpected with the option "Transpose". Obviously I missed > this point when writing the bug report. No problem. > This fact implies that my suggested interim solution has disadvantages. > Disabling "Paste Special" completely after cutting cells would disable > expected behaviour as well. Alternatively, only the "Transpose" option in > "Paste Special" could be disabled as interim solution. However, such a quick > fix lacks charm admittedly. Maybe there is no convincing interim solution. I think so yes.. Currently I see two options 1. just set a request to change the behaviour: Selecting Transpose should not affect the pasting of formulas. 2. as the UX-list... Think what would happen if we change as in option 1.. Would that rip users of the posibility of transposing without having formulas untouched? Of course the experienced user (and those using transposing are) could also use an extra step in another sheet?? Ideas?
(In reply to comment #5) > Hi Ady, > > I think that as well "Copy"/"Paste" as "Cut"/"Paste" behave well and as > expected in LibreOffice. MS Excel does not behave differently. Perhaps I wasn't clear enough. IMO, "Cut+Paste" is _not_ behaving "well" in Calc (just as bug #68976 describes too), and I think Excel (and others) indeed behaves differently. For example, you could perform one "Cut" task, and no "Paste" anywhere, just save the file and close it. The "Dependents" would have no clear and definitive formula for such case. In other words, a "Move Cell" action (a.k.a. "Select a cell and drag it to a different position") should not be the same as "Cut+Paste". When I *move* a cell, all "Dependents" of that cell keep track of it, thus correcting their respective formulas. That's not the same as "Cut+Paste" (at least, not in other spreadsheet tools). And since other spreadsheet tools (including popular ones) don't track such "Cut+Paste"-ed cells (their prior dependents keep their prior formulas intact), IMHO Calc should do the same. Hence, if there is a bug to be considered, then it is in the "Cut+Paste" action behaving as a "Move" (e.i. drag cell or range of cell) action. This corresponds to the initial description of bug #68976, "Formulas change after cut and paste action". I haven't tested each and all possible "Cut+PasteSpecial" possibilities, but generally speaking I would say that "Cut+Paste" in Calc should behave more as "Cut+PasteSpecial" in Calc (as in other spreadsheet tools), not the other way around. Perhaps there is an issue regarding “Transpose” too, but, as I said, I haven't specifically tested all “PasteSpecial” options before posting here. Regards, Ady.
(In reply to comment #7) > Currently I see two options > 1. just set a request to change the behaviour: Selecting Transpose should > not affect the pasting of formulas. > 2. as the UX-list... > > Think what would happen if we change as in option 1.. > Would that rip users of the posibility of transposing without having > formulas untouched? > Of course the experienced user (and those using transposing are) could also > use an extra step in another sheet?? > Ideas? Unfortunately, I do not get the hang of these two options. But you ask for ideas, so let me give it a try. Option A (nice and clean): LO Calc produces the expected result, which is described in the bug request and illustrated in the attached ODS spreadsheet. Ideally bug 68976 is fixed as well. I consider bug 68976 to be more severe than this one. Option B (quick and dirty): If cells are cut and if the "Paste Special" menu is opened subsequently, the option "Transpose" is shaded grey in the "Paste Special" menu and cannot be selected like after copying cells. I don't know how quickly option B could be implemented, but it is not as dirty as it might appear at first sight for three reasons: a) The change or loss of data of bug 68976 is avoided. b) No functionality of LO Calc is lost. "Copy" and then "Paste Special" with option "Transpose" works properly. The current behaviour of "Cut" and then "Paste Special" with option "Transpose" does not add functionality. It confuses (see this bug) or even leads to data loss or change (see bug 68976). c) It does not fall back behind MS Excel 2007 (I don't know about other Excel versions). If you cut cells with MS Excel and if you want to paste with options afterwards, the option to transpose is shaded grey and cannot be selected. So option B would fix something without losing anything. However, it's not great like option A. Does option 1 or 2 coincide with option A or B? Maybe I miss the point.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT *Update the version field *Reply via email (please reply directly on the bug tracker) *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-01
(In reply to QA Administrators from comment #10) The bug is still present without changes (LibreOffice 4.4.2.2, Windows 7).
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
(In reply to tommy27 from comment #12) The bug is still present without changes in version 5.1.2.2 (x64) with Windows 7.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.7 or 5.3.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170522
(In reply to QA Administrators from comment #14) The bug is still present without changes in version 5.2.7.2 (x64, Windows 7).
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to QA Administrators from comment #16) The bug is still present without changes in version 6.1.0.1 (x64, Windows 10).
Dear Ralf, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The bug is still present without changes in version 6.3.0.2 (x64, Windows 10).
Reproduced Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: eb6127e9aba2ad19cc5ad5c00ed4c67c5ee301af CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
I've found the problem. I'm working on a solution and automatic tests.
I've submitted a patch: https://gerrit.libreoffice.org/c/core/+/115535 Waiting for review
scito committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fd0779f6a0fd04263155d293320546ce7cbae84b tdf#71058 cut paste transposed: use correct clipdoc It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Roland Kurmann, please mark this bug as resolved. I verified this bug and it is solved. But I wait for your change on the status of this bug. Version: 7.2.0.0.alpha1+ / LibreOffice Community Build ID: 42d2b2d55a27f11153ea1713737d93540a19211d CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Verified again. It's fixed. Thanks for your work. Version: 7.2.0.0.alpha1+ / LibreOffice Community Build ID: ec629c5ee22d02f99d66a5cf975ce239876b7f4d CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded