In OpenOffice, the ascending sort button (represented by the icon showing A->Z or ) would sort everything EXCEPT the first row. (And vice versa for the descending sort button) I've switched to LibreOffice and am using 6.0.3.2. I've just found that the ascending sort button in LibreOffice also sorts the first row. That is useless. I also found that this problem appeared at least more than a year ago in version 5.3.2 and reported by another user at https://ask.libreoffice.org/en/question/91978/sort-column-labels/ But nobody answered his question!
Heiko/Xisco: should "Range contains column labels" be checked by default so the by default sort would consider first line as a label?
(In reply to Julien Nabet from comment #1) > Heiko/Xisco: should "Range contains column labels" be checked by default so > the by default sort would consider first line as a label? If by default (which it is in the sort dialog on my installation) that is good. But that does not appear to influence the behavior of the Ascending and Descending sort tool bar buttons actions. (when the sort dialog is not invoked). When those are used the option in the sort dialog has no effect. I would say the current behavior is a bug and for sort functions not triggered from the dialog box the behavior should be to defaulted to 'first row contains labels' when the user has selected a full column and should not have that option set when the user manually selects a range of cells. I would not use the setting from the sort dialog, as it becomes a hidden setting to most users.
Cannot reproduce with Version: 6.0.5.2 (x64) Build ID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16 CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: ru-RU (ru_RU); Calc: CL with steps: 1. Create a new spreadsheet 2. In A1-A5 enter: a, 1, 2, 3, 4 3. In B1-B5 enter: b, 4, 3, 2, 1 4. Select columns A:B 5. Sort using "Sort Ascending"/"Sort Descending" toolbar buttons. The "a" and "b" labels stay on top. It seems that no settings (in Options→LibreOffice Calc→Calculate, as well as in Sort... dialog) influence this. A screencast is at http://youtu.be/4-QJ7xR6plw?hd=1. Possibly some data is missing, like a specific locale, or details on the labels content that might influence the detection.
Looks contradictory with https://bugs.documentfoundation.org/show_bug.cgi?id=90393
Like Mike I cannot confirm the issue and following Miguel we should close this ticket as a dup. PS keyword needsUX needs to be accompanied by CC @ ux-advice... *** This bug has been marked as a duplicate of bug 90393 ***
(In reply to Mike Kaganski from comment #3) > Cannot reproduce with Version: 6.0.5.2 (x64) > Build ID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16 > CPU threads: 4; OS: Windows 10.0; UI render: default; > Locale: ru-RU (ru_RU); Calc: CL > > with steps: > > 1. Create a new spreadsheet > 2. In A1-A5 enter: a, 1, 2, 3, 4 > 3. In B1-B5 enter: b, 4, 3, 2, 1 > 4. Select columns A:B > 5. Sort using "Sort Ascending"/"Sort Descending" toolbar buttons. > > The "a" and "b" labels stay on top. It seems that no settings (in > Options→LibreOffice Calc→Calculate, as well as in Sort... dialog) influence > this. I have just tried this in ver 6.0.3.2 and indeed, sort buttons do not sort first row. However, when I open my own file and tried again, first row is still sorted. BUT I installed OpenOffice 4.1.5 to open the same file and the first row is NOT sorted. So, something is different between OpenOffice and LibreOffice and the behaviour in LibreOffice is very obscure. I'm going to attach a test file for you to try. > A screencast is at http://youtu.be/4-QJ7xR6plw?hd=1. Note that I don't select the columns and I don't need to. The normal behaviour (at least that in OpenOffice) is that we just need to select a cell of the column that we want to sort (except first row, I suppose) and all adjacent columns are sorted accordingly.
Created attachment 143271 [details] Test The data in this file are sorted correctly in OpenOffice but not in LibreOffice
(In reply to m.a.riosv from comment #4) > Looks contradictory with > https://bugs.documentfoundation.org/show_bug.cgi?id=90393 TL;DR But if the title of that bug tells everything about the bug, I do not agree with Regina. It's true that in some situation, first row is not header but data, but this should be an exception. If you check all of your data, I bet at least 99% of them have row headers. So, sorting first row should be considered as an *exception* because it's a minority case. (In reply to Heiko Tietze from comment #5) > Like Mike I cannot confirm the issue and following Miguel we should close > this ticket as a dup. > > PS keyword needsUX needs to be accompanied by CC @ ux-advice... > > *** This bug has been marked as a duplicate of bug 90393 *** How could this bug be marked as duplicated of the other bug while that one is in contradiction to what I described here? That's illogical!
On pc Debian x86-64 with master sources updated some days ago, I could reproduce the pb. In fact, in Horus' test file, there are only strings. On Mike's file, the first line only contains strings, the other just numbers. It seems Calc takes this into account to include or not in the sorting the first line.
(In reply to Julien Nabet from comment #9) > On pc Debian x86-64 with master sources updated some days ago, I could > reproduce the pb. > > In fact, in Horus' test file, there are only strings. > On Mike's file, the first line only contains strings, the other just numbers. > It seems Calc takes this into account to include or not in the sorting the > first line. That's what I thought too. This "semi-artificial intelligence" needs improvement....
(In reply to horus from comment #8) > How could this bug be marked as duplicated of the other bug while that one > is in contradiction to what I described here? That's illogical! Because your request is the same as in the other ticket, just in the opposite way. And I disagree that most sheets have a header. Plus, it's easy to recognize that your header wasn't sorted while it's hard the other way around.
(In reply to horus from comment #6) (In reply to Julien Nabet from comment #9) (In reply to horus from comment #10) The bug 91305 that I mentioned as See Also is where the change was introduced (and where reasons are given). I assumed that at least OP would notice that someone made another bug as "see also", and look into. Turns out that explicit explanations are necessary. When it comes to reasonings like "I tell you that most data in the wild have headers!" - "no I tell you that most are headless!" - these reasonings are always based on personal bias. If one mainly sees problems from one area, one necessarily takes one's situation as universal. But bugs in the tracker are more objective, and their count/CC numbers tells us more realistic picture. And until there are more substantial evidence that more people are affected by status quo than they were for previous state, I strongly advise *not* to change it. The logic tells, btw, that since current behaviour is consistent with that of Excel, then more people would be ready for and used to it, so changing this would affect more people in negative way.
(In reply to Mike Kaganski from comment #12) > But bugs in the tracker > are more objective, and their count/CC numbers tells us more realistic > picture. And until there are more substantial evidence that more people are > affected by status quo than they were for previous state... And based on this, I see marking this as a dupe for bug 90393 as *very* wrong move, since it makes the picture skewed drastically.
(In reply to Mike Kaganski from comment #13) > I see marking this as a dupe for bug 90393 as *very* wrong move... Right
As a reporter and fixer of the opposite bug I can tell that it is easy to deselect header row, but it's much more difficult to add header row if it doesn't exist only for the sake of sorting. I was taking into account the behavior of Microsoft Office Excel.