Problem description: Steps to reproduce: 1. Highlight cells to be sorted 2. Click Data menu, Sort 3. On Options tab, tick 'Range contains column labels' 4. On Sort Criteria tab, set appropriate criteria 5. Click Ok 6. The cells, including the column labels are sorted Current behavior: Does not ignore column labels when sorting Expected behavior: Ignore column labels when sorting Platform (if different from the browser): Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
I reproduce. Changing order of the steps (1, 2, 4, 3, 5) make this works. Similar to https://www.libreoffice.org/bugzilla/show_bug.cgi?id=52086. Selected options in "options tab" are not taken in account when you run the sort from first tab.
Seems like a general problem, several duplicates: Bug 54160, Bug 54036,
@Albert: Do you have time to look at this problem or should I take care of it?
@Marcus: I'll have a look at it this.
(In reply to comment #4) > @Marcus: I'll have a look at it this. Great. Couly you maybe also ad or extend the new unit test for sort with a test case. See http://cgit.freedesktop.org/libreoffice/core/commit/?id=332451bea5ebe08136de2d51e0e29cac88f89e8c
*** Bug 53994 has been marked as a duplicate of this bug. ***
Created attachment 66373 [details] proposed patch well I am not at all familiar with these crazy sfxtab things, in fact I spent an embarrassingly long time today looking at this. The attached patch seems to fix things, not completely sure if it is the correct fix :-) please have a look
Hmm, I'm struggling with being able to reproduce this bug myself. True it behaves like this in 3.6.0.4 but in the current master this problem does not persist. So I'm tempted to close this with WORKSFORME or whatever the right way would be in this case. Can somebody please check 3.6.1? because if it does we can really close it, IMHO. (In reply to comment #7) > Created attachment 66373 [details] [review] > proposed patch > > well I am not at all familiar with these crazy sfxtab things, in fact I spent > an embarrassingly long time today looking at this. The attached patch seems to > fix things, not completely sure if it is the correct fix :-) please have a look Ok, although this works, I can not see the need for Noels patch. It changes parts which I did not touch in my rewrite and I can't believe this fix is a direct cure for the regression. The big picture is that I'm planning to rewrite the dialog once more anyway (for 3.7 I hope) to get it more MSO 2007'ish and open up for sort by font/bg color...
this bug persists in 3.6.1.2 but not in current master.
*** Bug 54548 has been marked as a duplicate of this bug. ***
I just updated to the 3.6.2.2, 64-bit version of LibreOffice (Build ID: da8c1e6). I had this issue in the previous version I had installed (3.6.1.x) and wanted to see if it existed in this one. I see that it does. Please refrain from the detailed directions on how to sort using column headings as I do indeed know how to do so due to my status as a programmer/systems administrator which requires just a *bit* more knowledge than what is required to sort spreadsheets. This is, indeed, a bug though, as I have not yet tried it on any platform other than 64-bit Fedora, I am not sure it exists in other compilations.
I have just tried the same file in the MS-Windows version of LibreOffice (same build.) I got the same results.
It appears that (at least for me) this only happens when selecting a range approaching the whole page before sort. I selected a smaller range (i.e. the occupied cells only) and performed a sort that left the headers in the proper place. I then selected the whole page, minus the last row. The headers were then sorted into the data. Therefore, there is probably some critical point somewhere between a 50x1630 matrix and a page where this problem implements.
You may also have a look at https://bugs.freedesktop.org/show_bug.cgi?id=55485
Already [Reproducible] with Server Installation of "LibreOffice 3.6.0beta1 German UI/Locale [Build-ID: 1f1cdd8] on German WIN7 Home Premium (64bit) (and may be more early As also stated by Uwe Altmann, this problem might be related to the sort direction problem in "Bug 55967 - EDITING: Sorts columns instead of rows"
I asked for patch review on <libreoffice@lists.freedesktop.org>
*** Bug 54160 has been marked as a duplicate of this bug. ***
*** Bug 54360 has been marked as a duplicate of this bug. ***
*** Bug 55967 has been marked as a duplicate of this bug. ***
Noel Power committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1bc15304a3fb44399ebd3861f6ee5fc12197a969&g=libreoffice-3-6 exchange sort settings between the two tab pages, fdo#53482 It will be available in LibreOffice 3.6.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Power committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=76737b0fe2e8afa3248ceee5025415c807d8687b exchange sort settings between the two tab pages, fdo#53482 The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Power committed a patch related to this issue. It has been pushed to "libreoffice-3-6-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3f1219d1a659111f35302b6f1305fe7ce281501c&g=libreoffice-3-6-3 exchange sort settings between the two tab pages, fdo#53482 It will be available already in LibreOffice 3.6.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 55186 has been marked as a duplicate of this bug. ***
*** Bug 56588 has been marked as a duplicate of this bug. ***
Created attachment 70049 [details] Spreadsheet that bug will effect The attached spreadsheet has three highlighted sheets. The two red sheets are sheets where the bug still occurs, the third green sheet is a sheet where the bug does not occur.
I am reporting that the patch only partially solves this this bug in 3.6.3.2. I don't know exactly what the distinguishing issue is but I have attached the file that is causing problems. There are three color coded tabs at the bottom, two are read one is green. The first red sheet is my original sheet with all of my data spread over 40+ columns. The header row is actually starting on row 8. On this sheet is a cell highlighted in red that when sorted, will sort the header row. The second red sheet is a duplicate of the first however I highlighted 20 columns to the right of the sort column and pressed the "delete" key. The auto-filter drop down boxes are still visible in these columns. When the same cell is sorted, the same problem occurs. The third sheet is highlighted in green. This is also a duplicate of the first sheet but when instead of pressing the "delete" key to delete the columns to the right of the sort column. I highlighted the columns to delete and then right clicked, selected "delete columns" from the menu and then selected "shift cells to left". When sorting the cell highlighted in green, it will sort correctly. I hope that is sufficient information to track down the rest of this bug.
*** Bug 57184 has been marked as a duplicate of this bug. ***
*** Bug 56717 has been marked as a duplicate of this bug. ***
(In reply to comment #26) > I am reporting that the patch only partially solves this this bug in > 3.6.3.2. I don't know exactly what the distinguishing issue is but I have > attached the file that is causing problems. > > There are three color coded tabs at the bottom, two are read one is green. > The first red sheet is my original sheet with all of my data spread over 40+ > columns. The header row is actually starting on row 8. On this sheet is a > cell highlighted in red that when sorted, will sort the header row. > > The second red sheet is a duplicate of the first however I highlighted 20 > columns to the right of the sort column and pressed the "delete" key. The > auto-filter drop down boxes are still visible in these columns. When the > same cell is sorted, the same problem occurs. > > The third sheet is highlighted in green. This is also a duplicate of the > first sheet but when instead of pressing the "delete" key to delete the > columns to the right of the sort column. I highlighted the columns to delete > and then right clicked, selected "delete columns" from the menu and then > selected "shift cells to left". When sorting the cell highlighted in green, > it will sort correctly. > > I hope that is sufficient information to track down the rest of this bug. Please open a new bug report for it. Fixed bugs should not be hijacked for other bug reports. The original problem is fixed so your problem is a new bug.
*** Bug 56522 has been marked as a duplicate of this bug. ***
Zdeněk Crhonek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=35f8c6822ad012a9c7f33ec2173bef4e585875cb uitest for bug tdf#53482 It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The test exist, set status to Verified.