Libreoffice calc 4.2.7-0ubuntu1 not updating references after sort
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
LibreOffice |
Fix Released
|
Critical
|
|||
libreoffice (Ubuntu) |
Fix Released
|
High
|
Björn Michaelsen | ||
Trusty |
Fix Released
|
High
|
Unassigned |
Bug Description
Update to LibreOffice 4.2.7 is causing incorrect sort behaviour in Calc.
As initially reported here:
http://
Attached is sample Calc document. To reproduce, highlight B6 to E14, select Sort and sort by Column D, see that column E didn't get sorted.
ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: libreoffice (not installed)
ProcVersionSign
Uname: Linux 3.16.0-24-generic x86_64
ApportVersion: 2.14.7-0ubuntu8
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Nov 5 15:49:03 2014
InstallationDate: Installed on 2013-11-26 (344 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
SourcePackage: libreoffice
UpgradeStatus: Upgraded to utopic on 2014-10-08 (27 days ago)
In freedesktop.org Bugzilla #81633, JBF (jbf-faure) wrote : | #52 |
Set version number to unspecified because it affects development versions of each branch 4.2 and 4.3 and probably the master.
Version: 4.2.7.0.0+ Build ID: f5949d09321e3ac
Version: 4.3.1.0.0+ Build ID: f6445efb0e5c3de
Best regards. JBF
In freedesktop.org Bugzilla #81633, JBF (jbf-faure) wrote : | #53 |
After discussion on IRC, master is a better version number here.
Best regards. JBF
In freedesktop.org Bugzilla #81633, JBF (jbf-faure) wrote : | #54 |
Tested to be sure: reverting "fdo#81309: Adjust references during sort." http://
Best regards. JBF
In freedesktop.org Bugzilla #81633, Jmadero-dev (jmadero-dev) wrote : | #55 |
Confirmed
Ubuntu 14.04 x64
LibreOffice 4.4 master
Built: Mon Jul 21 13:38:10 2014 -0400
In freedesktop.org Bugzilla #81633, Libreoffice-0 (libreoffice-0) wrote : | #56 |
You guys need to talk to those users who think sorting should adjust references.
In freedesktop.org Bugzilla #81633, Libreoffice-0 (libreoffice-0) wrote : | #57 |
Calling this a regression is a testament to the meme that one man's feature is another man's bug. We all lose.
In freedesktop.org Bugzilla #81633, Libreoffice-0 (libreoffice-0) wrote : | #58 |
Our best option would be to make it configurable. Any attempt to automatically figure out when to and not to adjust would only make the situation worse, because unless we add a Google-level clever AI to do the guessing, we would never get it right, and there would always be some users with extreme corner cases coming out of the woodwork shouting "you broke my workflow!".
In freedesktop.org Bugzilla #81633, Jmadero-dev (jmadero-dev) wrote : | #59 |
@Kohei - whatever you think is best. I'm sure this is annoying for you having different users expecting different results :( If you want to mark as WONTFIX or as an enhancement as you described - whatever is best opinion.
Marking as bibisected since the commit has been identified.
In freedesktop.org Bugzilla #81633, JBF (jbf-faure) wrote : | #60 |
Created attachment 104016
another example of inconsistency in sorting
This attachment is the same as the previous except I have added a column with a formula using the OFFSET() function. This formula in column E gives the same result as the formula in column D. It is an attempt to keep the reference to the cell just above the current one.
If you select the range A2:E14 and sort ascending, you get several errors 523 in column E. Clearly it is not what is expected. If you do the same thing in LO 4.1.6 both columns still give the same result.
What is more inconsistent is that the sorting does not treat the part (Cn-Bn) in both columns the same way. It is updated in column D while it is not in column E.
As the change introduced by the fix for bug 81309 is big, I think it shouldn't be done in bugfix versions like 4.2.7 and 4.3.1. In other words, it is not a fix for a bug, it is a paradigmatic change.
Best regards. JBF
In freedesktop.org Bugzilla #81633, Guilleron29 (guilleron29) wrote : | #61 |
*** Bug 83391 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #81633, Jumbo4444 (jumbo4444) wrote : | #62 |
*** Bug 83276 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #81633, chris (ign-christian) wrote : | #63 |
*** Bug 83276 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #81633, Mariosv (mariosv) wrote : | #64 |
I think adjust it's fine, but in my understanding, sometimes wrong, it must be in the same way like Copy/Paste, adjust relative references and retain absolute references, like it is supposed a spreadsheet works. It's an user matter use properly relative/absolute references.
Now with sample in https:/
A9: =IF(C9<
changing C9 value to 500,
after Menu/Data/Sort - Column C descending / Options - Range contain column labels.
now in
A5: =IF(C5<
seems that references to the same row are updated properly (C5), but references to other rows change in a strange way for me (C8->C9), maybe they have several changes while sorting.
Forgive me, but I can't see why keep relative references changed in a different way than Copy/Paste, when a priori you don't know what data finish in what row.
I think most times comparisons/sums are with previous/next row, like in the sample, or to sum all the previous or all the rest rows/columns.
In freedesktop.org Bugzilla #81633, Dmdcaretwo (dmdcaretwo) wrote : | #65 |
(In reply to comment #13)
> A9:
> =IF(C9<
> sort";"")))
>
> changing C9 value to 500,
> after Menu/Data/Sort - Column C descending / Options - Range contain column
> labels.
> now in
> A5:
> =IF(C5<
> sort";"")))
>
> seems that references to the same row are updated properly (C5), but
> references to other rows change in a strange way for me (C8->C9), maybe they
> have several changes while sorting.
After sorting, the formula in A6 reads:
=IF(C6<
Similarly, A10 reads:
=IF(C10<
I agree that the references need updating properly - the current method updates some, but not all, relative references.
As far as I can tell, I now have no method of knowing reliably when to sort my tables - unless I copy a correct formula to all the rows after sorting my tables (not practical).
In freedesktop.org Bugzilla #81633, Libreoffice-commits (libreoffice-commits) wrote : | #66 |
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "master":
http://
fdo#81633: Add a new configuration option to toggle ref update on sort.
The patch should be included in the daily builds available at
http://
information about daily builds can be found at:
http://
Affected users are encouraged to test the fix and report feedback.
In freedesktop.org Bugzilla #81633, Libreoffice-commits (libreoffice-commits) wrote : | #67 |
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "master":
http://
fdo#81633: Write test for this.
The patch should be included in the daily builds available at
http://
information about daily builds can be found at:
http://
Affected users are encouraged to test the fix and report feedback.
In freedesktop.org Bugzilla #81633, Libreoffice-0 (libreoffice-0) wrote : | #68 |
This one is now configurable.
In freedesktop.org Bugzilla #81633, Jmadero-dev (jmadero-dev) wrote : | #69 |
Just FYI this will NOT be backported. So it'll be available in 4.4 daily in the next 24 hours.
In freedesktop.org Bugzilla #81633, Dmdcaretwo (dmdcaretwo) wrote : | #70 |
(In reply to comment #18)
> Just FYI this will NOT be backported. So it'll be available in 4.4 daily in
> the next 24 hours.
Forgive my ignorance but does that mean I will have to wait until 4.4 is published in early 2015?
why can the fix not be part of 4.3.3
In freedesktop.org Bugzilla #81633, Jmadero-dev (jmadero-dev) wrote : | #71 |
Do not reopen bugs that have been closed by a developer as FIXED.
I've talked to Kohei and he has reasons why it was not pushed to 4.3. If you want to look at the patch, review the patch, recommit the patch against 4.3, convince another developer to review that, etc. . . etc . . . you are free to do so. Else, yes, you will have to wait until 4.4. Removing myself from CC on this.
In freedesktop.org Bugzilla #81633, Jmadero-dev (jmadero-dev) wrote : | #72 |
One other thing - you are free to use 4.4 daily builds (not recommended but you are free to do so)
In freedesktop.org Bugzilla #81633, chris (ign-christian) wrote : | #73 |
*** Bug 83652 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #81633, Bondi3880 (bondi3880) wrote : | #74 |
*** Bug 84022 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #81633, JBF (jbf-faure) wrote : | #75 |
*** Bug 84157 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #81633, Adolfo Jayme Barrientos (fitojb) wrote : | #76 |
(In reply to comment #19)
> Forgive my ignorance but does that mean I will have to wait until 4.4 is
> published in early 2015?
>
> why can the fix not be part of 4.3.3
Because there is an UI and string freeze in effect for release branches; see https:/
In freedesktop.org Bugzilla #81633, Bondi3880 (bondi3880) wrote : | #77 |
AJ wrote
>You’re going to wait less than five months, not a big deal.
Some might say that's a rather cavalier attitude, perhaps?
The way I see it is that some one (or people) broke LO some releases back for a reason I don't understand.
Maybe 5 months is not a big deal to you, AJ, but I have to have LO working NOW the way it was - otherwise LO is as good as useless to me. :-(
I simply cannot mess around with daily builds for five months or retro-installing a previous version.
Fortunately there are alternatives that DO work as LO used to. Yep - us users are fickle, all right. :-D
Ian.
In freedesktop.org Bugzilla #81633, Dmdcaretwo (dmdcaretwo) wrote : | #78 |
I support Ian's comments.
I also wonder how many LO users have been sorting there data and not noticed the formulas have been corrupted.
In freedesktop.org Bugzilla #81633, Mariosv (mariosv) wrote : | #79 |
*** Bug 84390 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #81633, Iplaw67 (iplaw67) wrote : | #80 |
*** Bug 68566 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #81633, Bondi3880 (bondi3880) wrote : | #81 |
Hmmmmmm .... This bug has become an epidemic it seems and, like Ebola, it needs swift action NOW, seeing it was LO developers that caused it in the first place.
I've been in electronics engineering all my life and using spreadsheets since Lotus 123 came on the scene. Replacing something so basic (correct sorting) with something so esoteric I can't understand is sheer madness and totally reprehensible software development on the part of whoever introduced this new 'feature'. This 'new feature' is what should have been delayed and ADDED to 4.4. I can only hope LO software engineers have taken note and learned the lesson of not REPLACING long-established functions. Geez ... I hope Microsoft NEVER does away with the Vulcan Nerve Pinch (AKA Ctrl-Alt-Delete) :-D
At risk of being banned from this thread, I'm going to recommend that anyone who MUST have their Calc spreadsheets working properly have a look at Apache Open Office.org - the latest version works properly for me ... and my relieved customers.
STATUS: RESOLVED FIXED? I don't think so. Nothing has been resolved or fixed for us users.
In freedesktop.org Bugzilla #81633, chris (ign-christian) wrote : | #82 |
*** Bug 84754 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #81633, Scno (scno) wrote : | #83 |
I reported a duplicate of this bug. So I should be done. BUT, I have to really add my opinion here.
Ian is totally right. I am pissed off too. U can't do such a thing without a loud warning and not in a minor version.
I by myself was waiting that sort does not crash anymore or mixes up conditional formatting, not to speak off some printing stuff to be fixed. That were things I could see.
Now I thought all is working and U come up with some new hip functions which leads to silent corruption in tables I use for over 10 years!
U are so proud of Ur fast development cycle, think it over! Basic functions are just not working or have to handled with ugly workarounds, which never should have made it into an rc.
I am back at 4.1.6 I think. I don't know now, I have to check the other bugs which kept me from using the new versions.
I should create a bugs vs. versions matrix as a little helper to choose the right LO version for me, but I think I take sheet of paper in case I wanna sort this...
In freedesktop.org Bugzilla #81633, JBF (jbf-faure) wrote : | #84 |
I asked the ESC to revert this commit from branches 4.2 and 4.3
https:/
https:/
Best regards. JBF
In freedesktop.org Bugzilla #81633, Bondi3880 (bondi3880) wrote : | #85 |
Just a thought ...
Why not just replace the Calc program from 4.1.? (whatever the version that worked) into the next release and hold this "new feature" until 4.4?
Then those that absolutely must have this 'new feature' can keep on using the current version and those that want it to be the way it was can get on with the job of being productive again.
This 'new feature' has cost me a hell of a lot of time - not only working out what the problem was in the first place, but then having to placate hostile customers who blamed ME for stuffing up their spreadsheets.
I can see that no amount of strongly worded comments is going to get through the arrogance of developers, so I'm simply going to revert to, and stay with, Apache Open Office.
It is pointless staying with this bug report, so I'm removing myself from the CC list.
Good luck to all you others who want to wait for LO 4.4
Regards,
Ian.
In freedesktop.org Bugzilla #81633, Jumbo4444 (jumbo4444) wrote : | #86 |
Another way to avoid this new behavior if you are really annoyed is to switch back to LibO 4.1.6
http://
In freedesktop.org Bugzilla #81633, Luke (lukebenes) wrote : | #87 |
Kohei,
In 4.4 please change the default of Tools->
In freedesktop.org Bugzilla #81633, JBF (jbf-faure) wrote : | #88 |
Currently the configuration option in master (I guess it is menu Tools > Options > LibreOffice Calc > Update reference when sorting range of cells) does not solve the problem.
If you try to sort the test file (attachment 104016) whatever the choice you do (check or uncheck this option) the result is false:
1/ option checked: result false in column D and correct in column E
2/ option uncheck: error 523 (Calculation does not converge) in row 3 to 6 in both columns D and E.
NB1: a quick way to verify if the sort is correct is to check the last value in columns D and C; it must be 784.79 whatever is the order of the rows.
NB2: to sort the data I do that: click in A2 then select rows 2 to 14 (maintain Shift key and click on the row headers 2 and 14).
Best regards. JBF
In freedesktop.org Bugzilla #81633, Luke (lukebenes) wrote : | #89 |
Created attachment 107586
Screenshot showing how sorting is still broken even after the patch
Confirmed. The table is not sorting correctly with either option.
In freedesktop.org Bugzilla #81633, Luke (lukebenes) wrote : | #90 |
Created attachment 107601
Both Kingsoft and Gnumeric do NOT automatically adjust references when sorting
In freedesktop.org Bugzilla #81633, JBF (jbf-faure) wrote : | #91 |
(In reply to Jean-Baptiste Faure from comment #37)
> Currently the configuration option in master (I guess it is menu Tools >
> Options > LibreOffice Calc > Update reference when sorting range of cells)
> does not solve the problem.
I am pretty sure that I tested the fix right after it was pushed to the master and that it worked. I do not know what happened since this time. What is clear is that, now, it does not solve the regression.
Best regards. JBF
In freedesktop.org Bugzilla #81633, Photon713 (bobrass) wrote : | #92 |
I spent the better part of a day trying to figure out why my spreadsheets were not sorting properly. I've been using the same spreadsheets for the past 3 years. All of my values in this particular sheet were by reference to sheets, Points, Ringers and Master and used the usual $Points.A1 to $Points.V38 and the same for $Ringers and $Master. Basically, the same problem mentioned by many others, i.e., unusual results. Doing an UNDO left behind REF errors.
I was able to resolve the problem for this particular spreadsheet by doing a find and replace for every reference to read...
In freedesktop.org Bugzilla #81633, Qubit (qubit) wrote : | #93 |
A fix has already been released for this bug, so changing status from 'NEW' back to 'REOPENED'.
In freedesktop.org Bugzilla #81633, JBF (jbf-faure) wrote : | #94 |
*** Bug 84847 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #81633, Mariosv (mariosv) wrote : | #95 |
If someone is interested in a workaround, see my answer in:
http://
IMMHO, while we continue without a minimal previous QA for every new enhancement, not easy to find this kind of issues before release.
In freedesktop.org Bugzilla #81633, Scno (scno) wrote : | #96 |
I don't know the effort it takes to implement such a minimal QA.
But if it is not in reach, just don't add new enhancements in between minor version updates and definitely not between 4.2.6 and 4.2.7 - just fix bugs.
LibreOffice has matured and it has a strong user base. Bug hunting becomes now really important. It is definitely more important for me as a user then the next newest feature.
U loose more users by annoying bugs then winning new ones with a new feature.
I expect troubles for the X.X.0 Version but after then it must become better.
In freedesktop.org Bugzilla #81633, Fred Olness (olness) wrote : | #97 |
A COMPACT EXAMPLE OF THE BUG: ===================
Here is a compact example of the bug.
This is now fixed in the 4.3.4.0.0 2014-10-09 development version. (Thank you)
Note, this is clearly a BUG and not a FEATURE as this bug would break
imported spreadsheets from other programs (Excel, Gnumeric, ...)
In particular, this broke all my course grading spreadsheets.
EXAMPLE: if I consider the following spreadsheet
(which is sorted on the 1st column):
-------
ann fff =E1+F1+G1 =SUM(E1:G1) 1 2 3
barney eee =E2+F2+G2 =SUM(E2:G2) 4 5 6
charlie ddd =E3+F3+G3 =SUM(E3:G3) 7 8 9
-------
If I now sort on the 2nd column {ddd,eee,fff} the result is WRONG:
-------
charlie ddd =E1+F1+G1 =SUM(E3:G3) 7 8 9
barney eee =E2+F2+G2 =SUM(E2:G2) 4 5 6
ann fff =E3+F3+G3 =SUM(E1:G1) 1 2 3
-------
Note the relative references are handled correctly when I use
"=E1+F1+G1" but not when they are inside the argument of the
function: "=SUM(E3:G3)"
In freedesktop.org Bugzilla #81633, Fred Olness (olness) wrote : | #98 |
Created attachment 107658
Short example of the bug
This is a short (3 line) example of the bug.
In freedesktop.org Bugzilla #81633, Erik (erikalm) wrote : | #99 |
(In reply to Kohei Yoshida from comment #7)
> Our best option would be to make it configurable. Any attempt to
> automatically figure out when to and not to adjust would only make the
> situation worse, because unless we add a Google-level clever AI to do the
> guessing, we would never get it right, and there would always be some users
> with extreme corner cases coming out of the woodwork shouting "you broke my
> workflow!".
One thing that baffles me with the new sort is that it changes cells outside of the selected sort range.
If I wanted the sort to change the cells, for instance keep references to rows, I'd include those columns in the sort selection.
Would it help if the concept was that only cells in the sort selection should be changed? (It would at least help me a bunch and I think it would offer a workaround for those that expects cells to change all over the place).
You could also add a little checkbox in the sort dialog that said something like "Enable Hollistic Sorting" :D
Another clue (at least in my case) to when I don't want calculations to change with sort is when I have one or several columns of values and then one or several columns of formulas referencing the value-columns. And these formulas are identical part from the references that all uniformly address the same row as the formula cell or the same number of rows above/below the formula cell - I.e. uniformly referenced formulas
However a better option in this case is to insert an an empty column between the "data" cells and the "formula" cells and in that way keep sorting from selecting the formula cells when sorting, and as per above then keep sorting from changing the references in the formula cells.
/E
In freedesktop.org Bugzilla #81633, Scno (scno) wrote : | #100 |
Created attachment 107667
Test Case for cross sheet sort.
As I started to implement the workaround. I saw another annoying side effect.
I have a simple table without formulas on sheet1 and a summery by specific criteria on sheet2. These criteria are computed on sheet3. I made this division to let my users sort sheet1 without the risk of damaging any formulas.
What happens now is that on sheet3 with references to sheet1 the formulas are changed and sorted also.
So in sorting a table on one sheet I changed the formulas on another sheet.
I created a 2-sheet test case for this. Just sort sheet1 and see the effects on sheet2.
In freedesktop.org Bugzilla #81633, Michael-meeks-1 (michael-meeks-1) wrote : | #101 |
Wow; this bug is unreadably long & awful and seems to be collecting different problems.
Anyhow - Eike just merged the back-port of the option, defaulting to what should be the old behavior to the -4-3 branch, and it should be in the next 4.3 release (but not the one that is currently in progress AFAICS that'd be too much review work).
In freedesktop.org Bugzilla #81633, JBF (jbf-faure) wrote : | #102 |
Hi Michael,
Thank you very much for that. I saw the commit and I am currently trying to test my build. I do not understand how to check if the option is available in my installation. Where should I look ? In the install dir or in the user profile? Is it necessary to restart with a clean new profile to have this option working?
Best regards. JBF
In freedesktop.org Bugzilla #81633, JBF (jbf-faure) wrote : | #103 |
Ok, I found the option in the Expert Configuration window. Now, version 4.3 works the same way as 4.4 does. But in the case of the first attachment to this bug report (attachment 104016) both are currently wrong. It seems that the backward compatibility is not complete or broken somewhere. See comment #37 and comment #40.
Best regards. JBF
In freedesktop.org Bugzilla #81633, JBF (jbf-faure) wrote : | #104 |
I am closing this bug report, considering that the option UpdateReference
For the remaining bug on the operation of this option (Err:523), I have filed a dedicated bug report (bug 85215).
Best regards. JBF
In freedesktop.org Bugzilla #81633, JBF (jbf-faure) wrote : | #105 |
Created attachment 108255
Another example of inconsistency in sorting (updated)
Here is a new version of attachment 104016 in which I have removed useless validity list and restored missing headers of columns A, B and C.
Best regards. JBF
In freedesktop.org Bugzilla #81633, JBF (jbf-faure) wrote : | #106 |
*** Bug 85479 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #81633, JBF (jbf-faure) wrote : | #107 |
*** Bug 85405 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #81633, JBF (jbf-faure) wrote : | #108 |
From comment #8 in bug 85215 :
It works without error if, instead of selecting only the cell A1 and going to menu Data > Sort, I select the range A1:C14 (that is only the data) and sort on column "Date". It works the same if I select A1, hit the shift key and click on C14, or if I select the columns A, B and C and use the menu Data > Sort.
For me it is usable but it is a big change in the workflow which I was used to. I am sure I am not alone in this case.
Best regards. JBF
In freedesktop.org Bugzilla #81633, Dmdcaretwo (dmdcaretwo) wrote : | #109 |
Clearly the bug is still far from resolved and "For me it is usable but it is a big change in the workflow which I was used to" is unacceptable to me and, possibly, other users.
The sorting should work without users having to sort in specific ways.
There is, I believe, a strong case for removing the new functionality which has caused all these problems and for a considered approach to be taken the issue with it only being released when it works. I am hoping the developers have learned a lesson about releasing - let us not beat around the bush - half-baked functionality.
The release of the new functionality which corrupted formulae by sorting was unacceptable. The time it is taking to fix the bug is also unacceptable.
In freedesktop.org Bugzilla #81633, Luke (lukebenes) wrote : | #110 |
Jean-Baptiste,
Why have you closed this bug report? This serious issue has still not been resolved. Sorting now requires users to know workarounds and change settings that don't always work. This should remain open until sorting functionality has been restored to work in the same way as Excel, AOO, and LO 4.1 and earlier work.
In freedesktop.org Bugzilla #81633, JBF (jbf-faure) wrote : | #111 |
(In reply to Luke from comment #59)
> Jean-Baptiste,
> Why have you closed this bug report?
I explained in comment #53 why I closed this bug report.
> This serious issue has still not been
> resolved. Sorting now requires users to know workarounds and change settings
> that don't always work. This should remain open until sorting functionality
> has been restored to work in the same way as Excel, AOO, and LO 4.1 and
> earlier work.
I disagree, this bug report became unreadable. The issue in the original description is fixed by the option configuration. Ok, it is not perfect, that is why I submitted the problem to the ESC. The fact is that we have different needs for different situations. Sorting in some situations worked for years and some others did not work, for years too. The metabug bug 85490 try to summarize how sorting should work in different typical situations. Please, feel free to contribute to make the situation and the needs clearer.
Thank you for your understanding.
Best regards. JBF
In freedesktop.org Bugzilla #81633, Luke (lukebenes) wrote : | #112 |
Jean-Baptiste Faure,
Could you please give an example of a VALID spreadsheet that "did not work for years too"? The one "synthetic" example in your Meta is completely broken in Excel,Google Sheets, and never worked in any spreadsheet until recently. The "fix" for that Bug 45146 introduced this serious regression.
Thank you very much for following up with this report and with the ESC, but I do not think we can consider this issue resolved until the old functionality is restored.
In freedesktop.org Bugzilla #81633, Dmdcaretwo (dmdcaretwo) wrote : | #113 |
(In reply to Luke from comment #61)
>
> Thank you very much for following up with this report and with the ESC, but
> I do not think we can consider this issue resolved until the old
> functionality is restored.
I agree with Luke.
In freedesktop.org Bugzilla #81633, Nigelrmurray (nigelrmurray) wrote : | #114 |
Gentlemen,
As an outsider who has only begun reading about this issue (since the change in workflow affected me) I would like to add my perspective.
I think it is essential that default behaviour should not be changed in any mature application unless there is overwhelming evidence that the advantages outweigh the disadvantages. Furthermore, I think it is important (though not always essential) to mirror the default behaviour of significant competitors, in this case Excel.
The change in sort behaviour is so significant and so counter-intuitive for those of us coming from other products, that I believe it should not be made unless the default behaviour can remain compatible.
Just my $0.02 worth.
-Nigel
In freedesktop.org Bugzilla #81633, Gerard-fargeot (gerard-fargeot) wrote : | #115 |
*** Bug 85571 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #81633, Stephaniepar1972 (stephaniepar1972) wrote : | #116 |
The consensus appears to be that this issue is still not resolved. I wasted hours and lost data by making the mistake of upgrading to 4.3.2.2, the version that still offered on the website.
By the guidelines at https:/
That qualifies this as a serious bug eligible for back ports.
In freedesktop.org Bugzilla #81633, JBF (jbf-faure) wrote : | #117 |
Marc Deslauriers (mdeslaur) wrote : | #1 |
- test file Edit (17.8 KiB, application/vnd.oasis.opendocument.spreadsheet)
- ProcEnviron.txt Edit (106 bytes, text/plain; charset="utf-8")
Seth Arnold (seth-arnold) wrote : | #2 |
1:4.2.6.3-0ubuntu1 worked as expected
1:4.2.7-0ubuntu1 is broken as described on reddit
Launchpad Janitor (janitor) wrote : | #3 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in libreoffice (Ubuntu): | |
status: | New → Confirmed |
Marc Deslauriers (mdeslaur) wrote : | #4 |
Possibly relevant bugs:
Changed in libreoffice (Ubuntu): | |
assignee: | nobody → Björn Michaelsen (bjoern-michaelsen) |
importance: | Undecided → High |
Marc Deslauriers (mdeslaur) wrote : | #5 |
Also possibly relevant:
tags: | added: regresion-update |
Changed in libreoffice (Ubuntu): | |
status: | Confirmed → Triaged |
tags: |
added: trusty removed: utopic |
Björn Michaelsen (bjoern-michaelsen) wrote : | #7 |
1/ LibreOffice did not update references correctly and consistently on sort before 4.2.x/trusty in general before 4.2.7
2/ There are sets of users that want references to be updated by a sort. There is an equal set of users who want references to _not_ be updated by a sort.
3/ _Not_ updating references after a sort considered closest to the previous LibreOffice 4.2.x/trusty behaviour
As such the current package in by default does _not_ update references after a sort, but offers a "UpdateReferenc
The current behaviour in 4.2.7-0ubuntu1 is _not_ a regression as -- as noted above -- LibreOffice 4.2.x/trusty did not update references consistently anyway, despite examples existing were it did. So 4.2.7-0ubuntu1 behaves as close as possible to the 4.2.x/trusty series, but offers the option to update references too (but its not the default, because that would be a different behaviour from the one in previous 4.2.x/trusty).
This has been extensively discussed upstream:
https:/
https:/
https:/
https:/
http://
also note the number of reviewers/testers on the related patches:
https:/
https:/
Björn Michaelsen (bjoern-michaelsen) wrote : | #8 |
quoteing from the ESC minutes linked above:
+ both sides seem to think they are right (Kohei)
+ https:/
+ https:/
Björn Michaelsen (bjoern-michaelsen) wrote : | #9 |
The 4.2.7-0ubuntu1 package should now satisfy the fdo#81633 (Sorting shouldn't always automatically adjust references.) users, while the fdo#81309 (Sorting should automatically adjust references.) need to enable the UpdateReference
tags: | removed: regresion-update |
penalvch (penalvch) wrote : | #10 |
Björn Michaelsen, thanks for the quick clarification. I've hidden my comment so as not to confuse anyone on this.
However, by default in Microsoft Excel 2013 15.0.4659.1001 it allows sorting of relative references in the attached spreadsheet. Perhaps this discussion should be carried upstream, but it would seem both allowing this default behavior for Excel expectation compatibility purposes, and allowing the changing of this behavior from the commits in https:/
Björn Michaelsen (bjoern-michaelsen) wrote : | #11 |
Here is a quick and dirty way for those who want the fdo#81309 behaviour (Sorting should automatically adjust references.):
sudo vim /usr/lib/
Search for:
<prop oor:name=
and replace it with:
<prop oor:name=
Björn Michaelsen (bjoern-michaelsen) wrote : | #12 |
Note that the upcoming LibreOffice 4.4.x will default to the fdo#81309 behaviour (Sorting should automatically adjust references.) behaviour and have an option in the UI to go back to the fdo#81633 (Sorting shouldn't always automatically adjust references.) behaviour.
summary: |
- Libreoffice calc 4.2.7 not sorting right + Libreoffice calc 4.2.7 not updating references after sort |
summary: |
- Libreoffice calc 4.2.7 not updating references after sort + Libreoffice calc 4.2.7-0ubuntu1 not updating references after sort |
Luke (lukebenes) wrote : | #13 |
Björn,
> 1/ LibreOffice did not update references correctly and consistently on sort before 4.2.x
You are confusing the issues here. No spreadsheet software consistently updates or does not update references, because there are many types of references. However, there is a well established behavior that
a) Sorting RELATIVE references does not update
b) Sorting ABSOLUTE references does update
All spreadsheet software followed this behavior, including LibreOffice before 4.2.x, Gnumeric, Google Sheets. WPS Sheets, and EXCEL
> There is an equal set of users who want references
Equal? Over the past few years there have just been a few bug reports asking for the new sort behavior. These were filled out by users who admittedly are new to spreadsheets and do not know how to use absolute references. In just a few weeks, this new sort has caused dozens of bug reports like this one and all the dupes of Bug 81633. In fact the [Meta] Bug 85490 that's supposed to track usecases could only find ONE synthetic example that could easily be FIXED with absolute references.
> Note that the upcoming LibreOffice 4.4.x will default to the fdo#81309 behaviour (Sorting should automatically adjust references.)
By changing the behavior to update references, you will be insidiously breaking spreadsheets. Unless the users are looking at the formula, they may not realize that newly sorting spreadsheets are giving invalid results like https:/
Why are we breaking old spreadsheets and interoperability for a few users that don't know how to use absolute references?
Manuel Iglesias Alonso (glesialo) wrote : | #14 |
I just want to point out that if sorting (of block in 'test file' above) were to be done 'by hand' (cutting and pasting rows), the result would be the same as with the old style LibreOffice sorting.
JBF (jbf-faure) wrote : | #15 |
I think that the issue described here has nothing to do with the value of the option UpdateReference
Best regards. JBF
Björn Michaelsen (bjoern-michaelsen) wrote : | #16 |
@JBF: Wrong. If you execute the steps in comment #11 it works as expected by the proponents of fdo#81309 (Sorting should automatically adjust references.).
Manuel Iglesias Alonso (glesialo) wrote : | #17 |
@Björn Michaelsen: You are right. As I am not familiar with vim I have written a bash script to modify '/usr/lib/
#!/bin/bash
FileToModify=
OrgLine='<prop oor:name=
CorrectedLine=
mv "$FileToModify" "${FileToModify
cat ${FileToModify}.bak | sed 's%'"${
######### END OF SCRIPT ################
Use it this way:
sudo ./Script
JBF (jbf-faure) wrote : | #18 |
Hi Bjoern,
I didn't say the contrary, I said that, with LO 4.3.4.0.0+ and LO 4.4.0.0.alpha1+, it works too as expected if the option is set to false. It should be the same in LO 4.2.7 because the value false for the option is intended to be there for backward compatibility. So if it does not work as expected with option set to false, it is a bug.
Best regards. JBF
In freedesktop.org Bugzilla #81633, JBF (jbf-faure) wrote : | #118 |
*** Bug 85571 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #81633, Luke (lukebenes) wrote : | #119 |
*** Bug 85968 has been marked as a duplicate of this bug. ***
Matthias Ferdinand (mf+ubuntu1) wrote : | #19 |
Hi,
this update broke several of my spreadsheets that I use regularly, and have been using even back with StarOffice, then OpenOffice and finally LibreOffice for years. While the Ubuntu patch makes it sort in some way different from the "New LO way of updating References", it still breaks.
This is a major break/change in functionality on an LTS platform and just "should not happen(TM)".
For the time being, I have reverted the upgrade and put the libreoffice packages on hold using apt-mark.
Regards
Matthias
Björn Michaelsen (bjoern-michaelsen) wrote : | #20 |
As a clarification TDFs 4.2.7 release _does_ update references, while Ubuntus 4.2.7-0ubuntu1 by default does not (see comment #17 on how to change that). So:
- TDFs 4.2.7 release shows fdo#81633, but not fdo#81309
- Ubuntus 4.2.7-0ubuntu1 by default shows fdo#81309, but not fdo#81633
Both bugs are mutually exclusive.
For completeness it shall be noted that the original poster on reddit complains about references not being updated after sort in Ubuntu 4.2.7-0ubuntu1 (so he agrees with the reporter of fdo#81309: "Sorting should automatically adjust references."), to which the first commenter on reddit links to fdo#85614 against TDFs builds, which says: "Sorting should automatically adjust references is an ill conceived enhancement.". Apparently these two reddit users are not aware that they have exactly opposing opinions on the expected behaviour.
In fact, switching back Ubuntu default behaviour to the one of TDFs upstream 4.2.7 release by default, while making the reporters of fdo#81309 happy, would just exchange that for those who want fdo#81633 to be resolved.
Repeating again: Comment #17 has a quick way to toggle the default behaviour.
Manuel Iglesias Alonso (glesialo) wrote : | #21 |
@Björn Michaelsen: I am reddit OP. I think that distinguishing sorting behaviour by '(not)adjusting references' is prone to confusion (more below). I prefer to use 'old' or 'new' style LibreOffice sorting. 'old' meaning the standard sorting behaviour in all spreadsheet software and LibreOffice up to version 4.2.x.
For me (see #14 above) sorting is a tool that allows me to do painlessly what I could do 'manually' by, laboriously, inserting/removing, cutting and pasting rows. Seen in that light the 'old' sorting style is also the logical one: When I cut and then paste (to a different position) a row of cells the formulae which do not use absolute references are automatically adjusted (i.e. a reference to the cell to the left is maintained) and, therefore, there is no need for more adjusting after (manual) sorting.
Luke (lukebenes) wrote : | #22 |
@Björn Michaelsen
> The 4.2.7-0ubuntu1 package should now satisfy the fdo#81633
Please try the attached test file along with the attached test cases in 81633 such as test_offset.ods and Calc bug.ods. None of these work with Ubuntu's Calc 4.2.7.2, but worked just fine under 4.2.6.
> Apparently these two reddit users are not aware that they have exactly opposing opinions on the expected behaviour.
As Manuel pointed out, what people want is the old sorting behavior back. They're probably using the wrong terminology because this change is confusing and requires toggling a secret option (update refs) that is not well documented.
While 4.2.6 may not have been perfect, as least it mostly followed the industry conventions of updating relative references, while never updating Absolute references. It did this automatically, without the need to toggle any settings that require a restart. Take a look at the use cases in FDO# 85490 to see how many spreadsheets sorted fine in 4.2.6 and Excel but with 4.2.7 there is no clear UpdateRefs setting that always works.
To be clear, with 4.2.7 there is no way to return to the old style sorting routine. Some spreadsheets that worked fine in Excel and 4.26 require UpdateRefs=True, while others require it to be false. Others are broken with either UpdateRefs setting because of bugs introduced in this new sorting routine. Is it any wonder users are confused?
In freedesktop.org Bugzilla #81633, JBF (jbf-faure) wrote : | #120 |
*** Bug 86170 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #81633, JBF (jbf-faure) wrote : | #121 |
*** Bug 83864 has been marked as a duplicate of this bug. ***
Matt Malone (m-j-malone) wrote : | #23 |
I configured a new machine with Ubuntu 14.04 months ago. I have been gifted with LibreOffice 4.2.7.2. I was using Ubuntu 12.04 before that, and had LibreOffice 4.1.something. Before that I was using OpenOffice, before that Excell, before that Easy-as-123. All of them update references consistently. I have never noticed an inconsistency in them in about 25+ years of using spreadsheets.
With 4.2.7.2 I immediately noticed that I was unable to sort all 2582 rows of my spreadsheet at once -- it simply crashed. (a different bug)
I have been working with 4.2.7.2 now for MONTHS and only today did I find that it does not sort references properly.
You cannot imagine my disappointment. You cannot imagine the time it is going to require to unmangle this spreadsheet if that is at all possible. It represents 8 years of my work.
Luke (lukebenes) wrote on 2014-11-06:
>Why are we breaking old spreadsheets and interoperability for a few users that don't know how to use absolute references?
Absolutely. Nothing else needs to be said. If the people who want a different type of reording the contents of rows of a spreadsheet want it to do something non-sensical, then, add a new and completely different function called MANGLE and leave SORT alone to work has it has for decades. Sort should work exactly and only like one resorted the sheet by hand by cutting and pasting entire rows. Anything else just violates the entire concept that rows are records and must stay together. If your rows do not represent records that must stay together and you want a result that cannot be achieved by cutting and pasting entire rows then you want to do something other than SORT.
This comment represents only a tiny fraction of the time I will spend correcting the months of mangling caused by this stupidity.
Matt Malone (m-j-malone) wrote : | #24 |
My greatest fear now is all those people who still have not realized this is happening, and, are still in the process or mangling spreadsheets. Until Libre Office releases a patch retroactively fixes all 4.2.7.2 installations on all Ubuntu 14.04 installations, AND pops up a special window when people try to sort in future, telling them that "sorry for months you have not been sorting spreadsheets but rather mangling them, don't worry though, now it works correctly again, sorry for the loss of years of work" then these people will go on mangling spreadsheets
This is to the point of saying Ubuntu 14.04 should be withdrawn to prevent any further damage. It is just not worth it if it damages years of work.
If this is not the end of LibreOffice, I do not know what will be.
penalvch (penalvch) wrote : | #25 |
Björn Michaelsen, to get back to https:/
In Trusty, after performing the advised edit of main.xcd, and then closing the file, immediately attempting to open any file, or just Calc itself consistently crashed. For example, via a terminal:
localc
terminate called after throwing an instance of 'com::sun:
The crash report on this was sent to errors.ubuntu.com, and https:/
Unfortunately, reverting the edit doesn't fix the crashing. However, what does is uninstalling, and reinstalling via a terminal:
sudo apt-get -y remove libreoffice-core libreoffice-
Would I be missing something on the WORKAROUND procedure?
lsb_release -rd && apt-cache policy libreoffice-calc
Description: Ubuntu 14.04.1 LTS
Release: 14.04
libreoffice-calc:
Installed: 1:4.2.7-0ubuntu1
Candidate: 1:4.2.7-0ubuntu1
Version table:
*** 1:4.2.7-0ubuntu1 0
500 http://
500 http://
100 /var/lib/
1:
500 http://
Björn Michaelsen (bjoern-michaelsen) wrote : | #26 |
for reference:
http://
Manuel Iglesias Alonso (glesialo) wrote : | #27 |
@Björn Michaelsen: I would never write something like the example in http://
Manuel Iglesias Alonso (glesialo) wrote : | #28 |
The longer the current libreoffice calc version stays in popular distros the more spreadsheet documents will be mangled by sorting. Both distro and libreoffice will be blamed (and hated).
Couldn't you update to a (newer) version that has the old sorting style as default?
In freedesktop.org Bugzilla #81633, Matt Malone (m-j-malone) wrote : | #122 |
Making this change to LibreOffice 4.2.7.2 has broken many very old spreadsheets and caused them to be mangled in sorting. There is no way to resolve this post with this one:
https:/
I am in that camp. I want sorting to stay as it was, the sorting that keeps old sheets sorting exactly like Excel and 4.2.6 did.
However, I hear you and I have a suggestion. First lets revisit what we think sorting should be. IMHO, sorting is equivalent to cutting and pasting entire rows of the sort range and by hand manually reordering them. Note, I did not say COPY and paste. Copy and cut do different things to references depending on whether the reference in the sort is to a cell that is inside or outside the copy or cut region, and whether it is a A1, $A1, A$1, $A$1 reference. Further, for references that appear in cells outside the copy/cut range but (before the operation) refer to cells inside the range, there are again adjustments made.
For instance, when I cut and paste a range, A1 references to a location inside the range are changed, A1 references to a place outside the range are not. If I copy and paste, both are changed, that is why we have $ to keep selected references from being changed in a copy and paste.
The way copy/cut and insert columns/rows works makes spreadsheets work in a way that is common so spreadsheets with all forms of $ references (not code) can be moved from one program to another and work. If you break that, you greatly change the outlook for LibreOffice.
However, I hear these people. I suggest a new character with a new action "!" so that !A!1 is not changed ever, not by copy, not by paste, not by sort. The people who wanted this change can decide what they want the action to be of a reference to !Z!100 in A1 to be when inserting rows/columns at M50. I will live with what they decide.
I believe this will meet the desires of "bug" post.
Matt Malone (m-j-malone) wrote : | #29 |
Some may arrive here and be confused about that to do, given comments #22 and #25.
How do I end any possibility of corrupting my spreadsheet with LibreOffice? This is how
I ended the on-going damage to a years-old spreadsheets. I opened a terminal and pasted this:
sudo apt-get remove --purge libreoffice* libexttextcat-data* && sudo apt-get autoremove
I got that from a A00 page describing how to remove LibreOffice and install AOO. I was
sorely tempted to just keep following their instructions. But I decided that an old version
of LibreOffice untouched by this enhancement stupidity would be adequate. I found a link to
LibreOffice 4.1.6.2 navigated to x86-64 as my desired version and downloaded it with firefox,
landing in my Downloads directory:
http://
I then went to my Downloads directory:
cd ~/Downloads
tar -zxf LibreOffice_
cd LibreOffice_
sudo dpkg -i *.deb
I left that in my downloads directory in case anyone can
give me a compelling case to try another version and
risk years of work on it. If it does not work, I can repeat:
sudo apt-get remove --purge libreoffice* libexttextcat-data* && sudo apt-get autoremove
cd ~/Downloads/
sudo dpkg -i *.deb
And get back to something I am sure works for me. 4.1.6.2
behaves in a way consistent with other spreadsheet programs.
Other versions might work for you.
I have appreciated that a Google search has solved all my Ubuntu
problems in the past when I discover recipe pages with copy and
paste command lines. I hope mine work for you.
My version immediately asks me if I want to upgrade
NO THANKYOU
When no one has reported a mangled spreadsheet for months,
then I will consider it.
Manuel Iglesias Alonso (glesialo) wrote : | #30 |
@ Matt Malone & Christopher M. Penalver: I usedthe the script in #17 to modify (LO calc 4.2.72) '/usr/lib/
Manuel Iglesias Alonso (glesialo) wrote : | #31 |
I meant (LO calc 4.2.7.2) in my previous post.
Check this article:
http://
"He stressed that the issue has been corrected – the older sort function will be enabled by default in future versions,"
Björn Michaelsen (bjoern-michaelsen) wrote : | #32 |
@Manuel: Lets not link to articles that dont help triaging or solving this bug, this is not a mailing list or forum. Thanks.
P.S.: Also note that my fellow ESC and TDF Board member Michael Meeks is talking in that article about the upstream LibreOffice release, which -- unlike the Ubuntu 4.2.7-0ubuntu1 version -- _did_ update references and was criticized in fdo#81633 for that. Its very different from the issue in the Ubuntu release. But as noted: Please keep further discussion that is neither triaging or fixing this bug off this launchpad issue. Thanks.
penalvch (penalvch) wrote : | #33 |
Manuel Iglesias Alonso, in response to https:/
Hence, would you mind advising:
+ Which desktop environment(s) are you using where the WORKAROUND works for you in?
+ Are you using the upstream or downstream version of LibreOffice?
+ Are you using a 32-bit or 64-bit OS?
+ Could you please execute the following in a terminal and post the results here:
apt-show-versions -r libreoffice*
Manuel Iglesias Alonso (glesialo) wrote : | #34 |
@Björn Michaelsen: Sorry it won't happen again.
I thought the article was relevant because it shows that 'new style sorting' (MANGLING) is a temporary aberration:
SORTING ... MANGLING ... SORTING
Manuel Iglesias Alonso (glesialo) wrote : | #35 |
@Christopher M. Penalver:
Desktop: Cinnamon Mint 17
Libreoffice package: Distro standard update: LO calc 4.2.7.2
OS: 64 bit
apt-show-versions -r libreoffice*
libreoffice-
libreoffice-
libreoffice-
libreoffice-
libreoffice-
libreoffice-
libreoffice-
libreoffice-
libreoffice-
libreoffice-
libreoffice-
libreoffice-
libreoffice-
libreoffice-
libreoffice-
libreoffice-
libreoffice-
libreoffice-
libreoffice-
libreoffice-
Björn Michaelsen (bjoern-michaelsen) wrote : | #36 |
I just uploaded a version with additional fixes for fdo#82936, fdo#85282 to the ppa at https:/
In freedesktop.org Bugzilla #81633, JBF (jbf-faure) wrote : | #123 |
*** Bug 86304 has been marked as a duplicate of this bug. ***
Rowan Wookey (rwky) wrote : | #37 |
- brokenlibrecalc.ods Edit (33.0 KiB, application/vnd.oasis.opendocument.spreadsheet)
I've tested the build in the ppa with UpdateReference
Rowan Wookey (rwky) wrote : | #38 |
I downloaded Libre Office 4.3.4.1 from the Libre Office website and that works as expected.
Manuel Iglesias Alonso (glesialo) wrote : | #39 |
@Björn Michaelsen: I said in a previous comment:
> 'Couldn't you update to a (newer) version that has the old sorting style as default?'
Couldn't you update to Libre Office 4.3.4.1?
Björn Michaelsen (bjoern-michaelsen) wrote : | #40 |
@Manuel: "Couldn't you update to Libre Office 4.3.4.1?" no, Trusty stays on LibreOffice 4.2.x.
However this ppa:
https:/
usually has the newest upstream LibreOffice available and properly packaged. While not supported by Canonical, it is clearly better than manually installing the generic *.debs downloaded from libreoffice.org.
If you want to upgrade to LibreOffice 4.3.x but not beyond to e.g. 4.4.x, there is this ppa for that:
https:/
Both ppa have a version of 4.3.4.1 (= 4.3.4 final) for utopic and I assume ricotz (https:/
Apart from that, let me remind you again on the customs on this bug tracker: PLEASE STOP discussing things apart from triaging or fixing this issue here. Thanks.
Manuel Iglesias Alonso (glesialo) wrote : | #41 |
@Björn Michaelsen: Thank you.
According to 'Rowan (rwky)', updating to 4.3.4.1 would fix the issue.
Björn Michaelsen (bjoern-michaelsen) wrote : | #42 |
I just uploaded libreoffice-
Brian Murray (brian-murray) wrote : Please test proposed package | #43 |
Hello Marc, or anyone else affected,
Accepted libreoffice into trusty-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-
Further information regarding the verification process can be found at https:/
Changed in libreoffice (Ubuntu Trusty): | |
status: | New → Fix Committed |
tags: | added: verification-needed |
Bryan Quigley (bryanquigley) wrote : | #44 |
Did verification with the Short test case..
tags: |
added: verification-done removed: verification-needed |
In freedesktop.org Bugzilla #81633, Mariosv (mariosv) wrote : | #124 |
*** Bug 87106 has been marked as a duplicate of this bug. ***
Launchpad Janitor (janitor) wrote : | #45 |
This bug was fixed in the package libreoffice - 1:4.2.7-0ubuntu2
---------------
libreoffice (1:4.2.7-0ubuntu2) trusty; urgency=medium
* backport search & replace w/ empty performance fix (LP: #1342175)
* add additional backported upstream fixes for fdo#82936, fdo#85282,
fdo#85215, fdo#83765, fdo#79441, fdo#86708 (LP: #1389858)
-- Bjoern Michaelsen <email address hidden> Wed, 26 Nov 2014 19:24:35 +0100
Changed in libreoffice (Ubuntu Trusty): | |
status: | Fix Committed → Fix Released |
Brian Murray (brian-murray) wrote : Update Released | #46 |
The verification of the Stable Release Update for libreoffice has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.
Changed in libreoffice (Ubuntu): | |
status: | Triaged → Fix Released |
Manuel Iglesias Alonso (glesialo) wrote : | #47 |
I know that this bug is closed. But should not you wait for some user feedback?
In my opinion the updated Libreoffice calc still doesn't work correctly.
As I stated above: "sorting is a tool that allows me to do painlessly what I could do 'manually' by, laboriously, inserting/removing, cutting and pasting rows."
For me the correct sorting behaviour should be undistinguishable from sorting 'by hand'.
Find attached an spreadsheet document that, using the updated LibreOffice, behaves differently depending on the way ('by hand' or 'Data/Sort') a table is sorted.
Behaviour is the same if '/usr/lib/
Luke (lukebenes) wrote : | #48 |
@Manuel Iglesias Alonso
Please refer to:
http://
Your attached document is designed wrong. This is a classic mistake made by people who don't understand how spreadsheets function. If you sort it with Google Sheets, Excel, Open Office Calc, LO Calc 4.2.8, Gnumeric, or WPS sheets they will all produce the same, correct results. Why? You used references when you should be using a table lookup function.
If we change the default sorting behavior to fix your broken spreadsheet, all spreadsheets through out the history of spreadsheets software would be incompatible with Libreoffice's sorting routine. You can have your broken sorting behavior by changing the option UpdateRef=TRUE. But be warned: your spreadsheet will NOT sort correctly on any other spreadsheet software, include libreoffice with default settings. A much better solution is to design your spreadsheets correctly by using a lookup function.
Manuel Iglesias Alonso (glesialo) wrote : | #49 |
@Luke (lukebenes)
You are probably right but I noticed the described behaviour in existing spreadsheet documents that behaved as I expected with (OpenOffice) LibreOffice versions before 4.2.7.
It would be nice if somebody could test the documment, attached to my previous comment, with Excel and earlier versions of LibreOffice.
penalvch (penalvch) wrote : | #50 |
Manuel Iglesias Alonso, as this bug report is closed, and the scope of it Fix Released as outlined in https:/
However, if Luke's comments don't apply to your problem (i.e. this is a software bug, not a lack of knowledge regarding spreadsheet software, and in particular LibreOffice) please file a new report via a terminal:
ubuntu-bug libreoffice
Please feel free to subscribe me to it.
If Luke's comment do apply, you are welcome to engage Ubuntu support channels via http://
Thank you for your understanding.
Helpful bug reporting tips:
https:/
Changed in df-libreoffice: | |
importance: | Unknown → Critical |
status: | Unknown → Fix Released |
Luke (lukebenes) wrote : | #125 |
- Test2 with a lookup function instead of reference Edit (7.5 KiB, application/vnd.ms-excel)
@Manuel Iglesias Alonso
Both LO 4.1.6.2 and Excel 2013 will change B7=Customer1 after sorting. The issue is with your spreadsheet NOT with Calc’s sorting function. I have attached an example of how to correctly design a sortable spreadsheet to meet your desired goals. By using a lookup function, this spreadsheet will work in all spreadsheet software with default settings.
Please consider using other resources such as forums and Ask LO/Ask Ubuntu instead of issue trackers for help. Posting bug reports for software your unfamiliar with just adds noise to the development process.
Manuel Iglesias Alonso (glesialo) wrote : | #126 |
@Luke (lukebenes): Thanks.
In freedesktop.org Bugzilla #81633, Raal (raal) wrote : | #127 |
*** Bug 87317 has been marked as a duplicate of this bug. ***
Changed in libreoffice (Ubuntu Trusty): | |
importance: | Undecided → High |
The fix for bug 81309 seems to generate a regression in the behavior of some spreadsheet when sorting. Steps to reproduce:
1/ open attached file to bug 81617: https:/ /bugs.freedeskt op.org/ attachment. cgi?id= 103205
it is a simplified extract of bank account. Column D gives the balance between incomes (column C) and spendings (column B). Each formula in column D refers to the value in the previous row in the same column.
2/ select rows 8 to 14
3/ click on the button "Sort ascending" on the dates (column A)
The formulas in D8 and D14 are false. It worked in all previous versions of LibreOffice and OO.
Remarks: 099f0425825fe1e 6e8271dfb9 build at home (complete clean build) on Ubuntu 14.04 x86-64 62538df0e70e582 84bd1cab32)
a/ I discovered this regression on 4.3.1.0.0+ Build ID: f6445efb0e5c3de
2/ This bug does not affect 4.2.7.0.0+ updated and build one day ago
3/ this bug affects 4.2.7.0.0+ after backport of bug 81309 fix (Build ID: f5949d09321e3ac
Best regards. JBF