How it should be: When I have a cell with "=A1" in it and I cut/paste it somewhere else, the content stays "=A1". However, when I have a cell with "='file://somewhere/sheet.ods'#SheetName.A1" in it and I cut/paste it somewhere else, the reference is changed by the cut/paste offset. This problem does not occur when I have "='file://somewhere/sheet.ods'#SheetName.$A$1" and cut/paste it. So, it seems cut/paste with cross-file references behaves like copy/paste (which it should not).
Bodhi Moksha Version: 5.2.0.0.alpha0+ Build ID: aaca25d67eb5ea252730cdcf555ecc04ce04a5e6 CPU Threads: 2; OS Version: Linux 3.16; UI Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-02-24_23:58:47 Locale: en-US (en_US.UTF-8) Verified. Marking as: New Minor - won't prevent high quality work but can slow you down; Low - default for minor issues. It would be nice to find out if this is a regression - if you can help test older versions to find out if it ever worked that would be great. You can test 3.3 and if it didn't work there, then it never did ;)
Unfortunately, 3.3 crashes here on openSUSE 13.1 x86_64, so cannot tell... I am not so sure about classification as "minor" because it easily causes breakage of sheet logic, because it breaks the basic user assumptions when using cut/paste on formulas. Also, these errors are hard to spot.
Severity has no impact on when the bug gets fixed so don't stress over that. This is a volunteer project, if a volunteer finds it interesting, they'll take it on (regardless of if it's critical or minor). Minor is an objective definition: "can slow down but will not *prevent* high quality work. This obviously fits that
Ok, don't want to go too far OT but strictly speaking if I do what I always do to move a formula without changing its result and all over sudden, because of a very special detail of the formula, that workflow breaks, it quite profoundly prevents high quality work in my opinion. Anyway, you know better how to classify issues in this project - just to clarify why I wondered. And now, I hope this is interesting enough to get fixed!
(In reply to Tilman Vogel from comment #4) > Ok, don't want to go too far OT but strictly speaking if I do what I always > do to move a formula without changing its result and all over sudden, > because of a very special detail of the formula, that workflow breaks, it > quite profoundly prevents high quality work in my opinion. Yeah breaking workflow isn't enough to make it "preventing high quality work" - so long as there is a way to get it done (i.e., there is a workaround/different workflow) then it's minor ("can slow down . . . not prevent...") then it's minor :) > Anyway, you know better how to classify issues in this project - just to > clarify why I wondered. :) Always happy to see users interested in how things are done! > > And now, I hope this is interesting enough to get fixed! Indeed, just don't hold your breath :) There are several thousand bug reports, just a few dozen really active developers....the job they do is truly incredible
** 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.5 or 5.3.0 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-20170306
Still present in LibreOffice Calc 5.2.2.2 on openSUSE 13.1 (RPMs from libreoffice.org).
Hooray! Fixed in 5.3.0.3 (Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1) on openSUSE 13.1 (RPMs from libreoffice.org). Thanks a lot!