Bug Hunting Session
Bug 118471 - Sort button sorting also the first row
Summary: Sort button sorting also the first row
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.3.2.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-06-30 10:31 UTC by horus
Modified: 2018-07-04 23:44 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Test (9.22 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-07-02 17:14 UTC, horus
Details

Note You need to log in before you can comment on or make changes to this bug.
Description horus 2018-06-30 10:31:01 UTC
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!
Comment 1 Julien Nabet 2018-06-30 14:21:21 UTC
Heiko/Xisco: should "Range contains column labels" be checked by default so the by default sort would consider first line as a label?
Comment 2 Drew Jensen 2018-06-30 15:16:18 UTC
(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.
Comment 3 Mike Kaganski 2018-06-30 16:52:36 UTC
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.
Comment 4 m.a.riosv 2018-06-30 21:10:14 UTC
Looks contradictory with
https://bugs.documentfoundation.org/show_bug.cgi?id=90393
Comment 5 Heiko Tietze 2018-07-02 08:46:44 UTC
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 ***
Comment 6 horus 2018-07-02 17:13:18 UTC
(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.
Comment 7 horus 2018-07-02 17:14:31 UTC
Created attachment 143271 [details]
Test

The data in this file are sorted correctly in OpenOffice but not in LibreOffice
Comment 8 horus 2018-07-02 17:21:43 UTC
(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!
Comment 9 Julien Nabet 2018-07-02 17:23:54 UTC
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.
Comment 10 horus 2018-07-02 17:30:37 UTC
(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....
Comment 11 Heiko Tietze 2018-07-02 20:45:33 UTC
(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.
Comment 12 Mike Kaganski 2018-07-02 23:53:51 UTC
(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.
Comment 13 Mike Kaganski 2018-07-02 23:57:26 UTC
(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.
Comment 14 Heiko Tietze 2018-07-03 06:45:02 UTC
(In reply to Mike Kaganski from comment #13)
> I see marking this as a dupe for bug 90393 as *very* wrong move...

Right
Comment 15 Yan Pas 2018-07-04 23:44:51 UTC
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.