I can confirm with Version: 4.4.1.0.0+
Build ID: b460414bcd1dfd2f260696e306c49c56585c6464
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-4, Time: 2015-01-11_05:32:52

works in LO 3.5 -> regression

================================== it gets worse
When I had specified Range contains labels, had selected multiple columns and clicked OK (to sort) then clicked Save for the ods, then gone back to sorting to see what's saved and what's not saved, I found that it's also forgotten there were multiple columns as well as forgetting that the Range contains labels was ticked. Using the above, only column C would be shown, column B would not be shown as the second column. 
If it was working correctly, I'd have seen both labels.

It's not hard to verify that what I've reported is true...

bibisect result for the original bug description:
 743a6cc47f93aca3478e55e63cd29cdccfdcc3aa is the first bad commit
commit 743a6cc47f93aca3478e55e63cd29cdccfdcc3aa
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Sat Oct 18 10:56:40 2014 +0000

    source-hash-9dd5caac62083f7162d83319284df68ee83e3777
    
    commit 9dd5caac62083f7162d83319284df68ee83e3777
    Author:     Caolán McNamara <caolanm@redhat.com>
    AuthorDate: Mon Jul 14 11:36:32 2014 +0100
    Commit:     Caolán McNamara <caolanm@redhat.com>
    CommitDate: Mon Jul 14 11:48:32 2014 +0100
    
        Resolves: fdo#52226 swap in graphics on .docx and .rtf export
    
        Change-Id: Ie818b382c0b17760c720ff2f2c73a3697989f97e

----

$ git bisect log
# bad: [4a3091e95fa263d3e2dd81e56e83996f0bb12287] source-hash-2b5b04e1e62914bf0902dfd7943cdc44499c47a6
# good: [812c4a492375ac47b3557fbb32f5637fc89d60d9] source-hash-dea4a3b9d7182700abeb4dc756a24a9e8dea8474
git bisect start 'latest' 'oldest'
# good: [5d0dfb8e62ae61a240f8313c594d4560e7c8e048] source-hash-0c6cd530de13f80795881f61064f1bf1dcc4ea81
git bisect good 5d0dfb8e62ae61a240f8313c594d4560e7c8e048
# bad: [7dfacd0b8bd828331d74c0f79de6e8924bc4e6a5] source-hash-f93ce4f7eb90093d0ea3115d0a1c614612676dbd
git bisect bad 7dfacd0b8bd828331d74c0f79de6e8924bc4e6a5
# bad: [1a63057f6378db7c6b8af1171b7b140f7583f246] source-hash-59f84b4a2c082382767f12e0c7a06a3f0b52e721
git bisect bad 1a63057f6378db7c6b8af1171b7b140f7583f246
# good: [3787e4f82e47eaf4fa454afdca671272e50f875b] source-hash-0e09134a4a4cbb0639fc586c560c6fb2765487be
git bisect good 3787e4f82e47eaf4fa454afdca671272e50f875b
# good: [13c63ebe51bd9151757981f75b62271c00a47bf1] source-hash-5ccb510ef7dd6688b86038b37563583f64107936
git bisect good 13c63ebe51bd9151757981f75b62271c00a47bf1
# good: [2e44b89901b3478fac6251ab4fa87311bb8c256f] source-hash-91ebd8825bf0ac6bf3daaba54cefc1a11a64451d
git bisect good 2e44b89901b3478fac6251ab4fa87311bb8c256f
# skip: [b74dafb5d92d445ce1f441eeb81e717a1a78fb03] source-hash-87cb919c7ccf5aacda27b36781d5896eebbd182b
git bisect skip b74dafb5d92d445ce1f441eeb81e717a1a78fb03
# skip: [23eae1c9e288ecd9bb5e66a00f9bfc346982ae55] source-hash-2e6abb5d910f4813b75f86860c0b84ca01d98093
git bisect skip 23eae1c9e288ecd9bb5e66a00f9bfc346982ae55
# bad: [743a6cc47f93aca3478e55e63cd29cdccfdcc3aa] source-hash-9dd5caac62083f7162d83319284df68ee83e3777
git bisect bad 743a6cc47f93aca3478e55e63cd29cdccfdcc3aa
# good: [d92e2b18cdd1a97a6020d65655ccb730e4b5df78] source-hash-a7706f8a4e79fd36a296e988f7f852dfd549a16f
git bisect good d92e2b18cdd1a97a6020d65655ccb730e4b5df78
# first bad commit: [743a6cc47f93aca3478e55e63cd29cdccfdcc3aa] source-hash-9dd5caac62083f7162d83319284df68ee83e3777

This appears to have changed as of the below commit.

commit 5c6ee09126631342939ae8766fe36083d8c011e3
Author: Kohei Yoshida <kohei.yoshida@collabora.com>
Date:   Mon Jun 2 18:29:27 2014 -0400

    fdo#81309: Adjust references during sort.
    
    Change-Id: I2b98610f6b774400ecfaffe2905201c27fcab33f

and it's still in 4.4.1.2

and still there in 4.4.2.2 which was downloaded today (half hour ago)

and still there in 4.4.3.2
doesn't anyone test their changes before releasing?

I bumped this up to High + Major to get someone's attention.
Yes, there's a 'workaround', simply make the necessary changes before sorting.
But this is a PITA because I sort constantly and do not like having to 'fix' the sorts myself.
And sorting and saving settings is not something 'new', sorting has been around for a long time and it's worked properly up until someone made some stupid error regarding the saving of the settings (or perhaps over-writing the settings).

Still exists in 4.4.4.3 when installed 2015-06-30.

Would someone please shake the tree and get this fixed?

If someone forgets to mark the 'Range contains column labels' before sorting then they have to find the row and manually move it back to row 1.

This used to work. 
Someone 'broke' it.
That Someone should fix that which they 'broke' rather than screw around with something new which they can then also 'break'.

If That Someone has quit, then a new someone with better skills and attitude should jump in and fix it. It can't be that hard to do (it was easy to break).

@ Matthew Francis

It was impossible to add kohei.yoshida@collabora.com to the CC list.
I sent him an e-mail which failed due to an unknown address.

This guy has disappeared.

well it seems his new e-mail is libreoffice@kohei.us

I added him to the CC list

but after doing that, he was excluded from getting an e-mail.... Why? He's the likely "That someone" (after reading through bug 81309)

I assigned this to libreoffice@kohei.us just to see if he's aware of this.

Your action in this bug and the mail to Kohei are rude.

Before you request that anyone volunteers their time you should work on your manners.

This is a normal bug like many others that someone will fix when he/she finds the time.

(In reply to Markus Mohrhard from comment #15)
> Your action in this bug and the mail to Kohei are rude.
> 
> Before you request that anyone volunteers their time you should work on your
> manners.
> 
> This is a normal bug like many others that someone will fix when he/she
> finds the time.

Then suggest a better way to get the bug fixed.

When someone creates a bug (breaks something that worked before, probably without fully testing) and then quits, "bad manners" should not be the primary issue.

Simply letting the bug sit there until someone else decides to fix it is hardly an appropriate attitude. In the business world, the bug would get top priority.

@ Aprax
I do not understand your procedure. Why do you need step 3) "Select whole sheet"?
If you skip this step, there is no bug from my point of view.

@ Laurent

Your approach may be OK when sorting on only one column.

I want to sort on multiple columns (3 to be specific).

Using your suggestion, when I click on the most important column and select Sort then the "Range contains column labels" is ticked 
*but*
I can't select the second and third columns. So Step 3 is critical.

Thanks for trying,

J

Created attachment 116971 [details]
testcase to sort

@Arax
You should give a test case because I cannot reproduce your bug. My procedure:
1. Open attached file
2. no click, just directly select menu: Data > Sort
Table is automatically selected, "Range contains column labels" is ticked, 1st and 2nd criteria are saved.
Note: I made no selection at all.

From my point of view there is no bug, because if you explicitly make a selection different from previous sorting, then Calc think you want to change your options and try to find on first row if there are labels. When you select whole sheet (or an area with empty columns), there is no label in some columns, so Calc unticked "Range contains column labels". When you select an area with text (no value) in all cells of first row, then "Range contains column labels" is automatically ticked.

Test made with Version: 4.3.7.2
Build ID: 8a35821d8636a03b8bf4e15b48f59794652c68ba

@ Laurent
"You should give a test case because I cannot reproduce your bug."

Test Case: Start at step 1) and perform all 15 steps.

1) Create a spreadsheet containing three (or more if you like)columns with labels in row 1 as follows:
- Column A="Date",
- column B="Time",
- column C="Activity"
 and enter data in a few rows, the data doesn't really matter.
2) Select a column which is to be the 1st (major) column of the sort, e.g. column C with label = "Activity"
3) Click on the upper left square to set the range to the entire sheet contents
4) Use Data | Sort to open the Sort controls
5) if this .ods had sort criteria entered previously the Labels (row 1) would be shown but now only the column letters are shown
6) click on the Options tab, tick  "Range contains column labels"
7) click on the Sort Criteria tab, the label of the selected column (Activity) is shown
8) specify another column using the drop down list of labels e.g. "Time"
9) click OK to execute the sorting
10) Save and close the file
11) Reopen the file
12) Select the same range as in step 2 & 3
13) Open the Data | Sort dialog again and see two columns C and B rather than "Activity" and "Time"
14) click on the Options tab, tick Range contains column labels
15) click on the  Sort Criteria tab and see both labels, "Activity" and "Time".

Then in your scenario, same spreadsheet,
1) Select Column C
2) Use Data | Sort to open the Sort controls
3) You get a popup asking if you want to sort only that column or extend to sort all columns, click the "Extend Selection" button.
4) the "Range contains column labels" is ticked (good)
5) the other two columns can be specified (good)

My complaint is that, in my scenario, I now have to click on the Options Tab and then tick the "Range contains column labels" before clicking the [OK] button.
This current behavior is new with V4.
Whereas before, in V3, the steps were:
1) Select the primary column (click the column letter)
2) click the upper left corner to select all columns and rows
3) Use Data | Sort to open the Sort controls, you see the correct Labels.
4) Click on [OK] (because the  3 columns and "Range contains column labels" were 'remembered'.

(In reply to Aprax from comment #20)
> Then in your scenario, same spreadsheet,
> 1) Select Column C
Please follow procedure I described: make NO selection. Calc will guess where are the data to sort.

If you do not want that Calc try to guess, then you can make a selection of what you want to sort. In your procedure, you make a selection that do not correspond exactly to the data you want to sort. So avoid those useless steps. With your procedure, making a selection give wrong information to Calc.


> My complaint is that, in my scenario, I now have to click on the Options Tab
> and then tick the "Range contains column labels" before clicking the [OK]
> button.
> This current behavior is new with V4.
> Whereas before, in V3, the steps were:
> 1) Select the primary column (click the column letter)
> 2) click the upper left corner to select all columns and rows
> 3) Use Data | Sort to open the Sort controls, you see the correct Labels.
> 4) Click on [OK] (because the  3 columns and "Range contains column labels"
> were 'remembered'.
With V4, skip steps 1) and 2) and all will be correct. :)

OK, I just clicked in cell B3 and did not click on any column letter.

I then went through Data > Sort and when the window popped up, 
Sort key 1 was "B", not the Label for column B. 

I checked the Options tab and the "Range contains column labels" was not ticked.

So your way doesn't work on my system which has LO V 4.4.4.3 installed.

and, I did specify three sort keys, they were 'remembered' on a subsequent sort, it was just the "Range contains column labels" that was forgotten.
:)

(In reply to Aprax from comment #22)
> OK, I just clicked in cell B3 and did not click on any column letter.
No need to click somewhere ;)
> I then went through Data > Sort and when the window popped up, 
> Sort key 1 was "B", not the Label for column B. 
Did you try with your file or the test case I proposed attachment 116971 [details] ?
If you try with your own file, please add it as an attachment as requested in comment 19

> So your way doesn't work on my system which has LO V 4.4.4.3 installed.
I tested also with LibO 4.4.4.3 and it works fine for attachment 116971 [details] : sorting options (with "Range contains column labels" ticked and two criteria "Gr" column B and "Name" column A) are correctly remembered.

I downloaded your test case to my PC and opened it and did not click in any cell.

I selected Data > Sort and the Sort Key 1 showed the letter "L", presumably because that's where you had left your cursor, in cell L3.

The "Range contains column labels" was un-ticked obviously.

So nothing was 'remembered'.

Is there some other setting that can impact what's happening?
I don't see anything obvious in:
Tools > Options > LibreOffice Calc > Sort Lists, or in
Tools > Options > LibreOffice Calc > General

I have this problem in many of my spreadsheets, not just one.
It's hard to remember, but with V3, after adding or changing or deleting in the body of a sheet, all I had to do was Data > Sort and click OK (for an oft used sheet).

There's one thing that I thought might affect this, I keep all .ods & .odt files on a separated drive G:, not on my C: drive. So I copied the file to C: and the problem remained.

Created attachment 116976 [details]
very simple sheet

I uploaded my 'test case' and called it "very simple sheet"

(In reply to Aprax from comment #25)
 
> I selected Data > Sort and the Sort Key 1 showed the letter "L", presumably
> because that's where you had left your cursor, in cell L3.
> 
> The "Range contains column labels" was un-ticked obviously.
> 
> So nothing was 'remembered'.

Why the hell did you try to sort empty column?
Data are from A1 to F13.
In your first comments, you select the whole sheet, now you click outside the data.

Just put focus on any cell of the table with data!

When I open Laurent' file, it works as expected with 4.4.4
" sorting options (with "Range contains column labels" ticked and two criteria "Gr" column B and "Name" column A) are correctly remembered."

@Aprax: You need to click inside the data range to be sorted first.
1) Open file
2) Click inside data range but make no selection
3) Data > Sort
4) Select criteria, OK
5) File > Save
6) File > Reload
7) Data > Sort
Options are remembered.

If you agree with this procedure, please set the status of the bug as "Resolved" > "Works for me"

(In reply to GerardF from comment #28)
> (In reply to Aprax from comment #25)
>  
> > I selected Data > Sort and the Sort Key 1 showed the letter "L", presumably
> > because that's where you had left your cursor, in cell L3.
> > 
> > The "Range contains column labels" was un-ticked obviously.
> > 
> > So nothing was 'remembered'.
> 
> Why the hell did you try to sort empty column?
> Data are from A1 to F13.
> In your first comments, you select the whole sheet, now you click outside
> the data.
> 
> Just put focus on any cell of the table with data!
> 
> When I open Laurent' file, it works as expected with 4.4.4
> " sorting options (with "Range contains column labels" ticked and two
> criteria "Gr" column B and "Name" column A) are correctly remembered."

I didn't *try* to sort an empty column. You said that I shouldn't click in any cell..... so I didn't, (the L3 was left by you as selected). Are you trying to complicate/confuse things?

(In reply to Laurent BP from comment #29)
> @Aprax: You need to click inside the data range to be sorted first.
> 1) Open file
> 2) Click inside data range but make no selection
> 3) Data > Sort
> 4) Select criteria, OK
> 5) File > Save
> 6) File > Reload
> 7) Data > Sort
> Options are remembered.
> 
> If you agree with this procedure, please set the status of the bug as
> "Resolved" > "Works for me"

OK, 
1) I opened my test case
2) I clicked in cell C7 because it has data.
3) Data > Sort
4) Sort key 1 was column C (and "Range contains column labels" was ticked)
5) I defined Sort keys 2 & 3 and clicked OK
6) I closed with option to Save
7) I opened and cell C7 is still 'chosen' but not by me clicking in it this time.
8) Data > Sort
9) yes, the options have been remembered.

10) I opened my real life spreadsheet
without going into step-by-step, the "Range contains column labels" would not be 'remembered' and that's my issue.

11) I created a new, empty file and then copied from the live file by selecting all the cells in 821 rows x Z columns, Copy/Paste and tried the sort
It had slightly different results. 
Initially Sort key 1 offered values of Row 1 to Row 821 when the "Range contains column labels" was unticked but once it was ticked, Sort key 1 contained the correct Label.
However Sort key 2 options were the label for column A or the contents of column A. I discovered that was because the Direction had been selected as left to right (sort columns) which I've NEVER used.
Once that was change to sort by rows, I could select the Sort keys 2 & 3, and then Closed and re-opened the file and lo and behold, the "Range contains column labels" was not 'remembered'.

So, I'm going to try to attach my real sheet for you to see what happens.

Created attachment 116987 [details]
my real file

The problem with your document attachment 116987 [details] is in cell L1: if you want it as a label, it must be text not value.
Solution:
1) move L1 outside your data range to sort, for instance AB1 (keep at least 1 empty column with your data),
2) enter a label in L1
3) click in a cell inside your data
4) Data > Sort
"Range contains column labels" is ticked and criteria are remembered.

The behavior is the same with LibO 4.0.6. So, from my point of view there is no regression, no bug. Change status of the bug if you agree.

(In reply to Laurent BP from comment #33)
> The problem with your document attachment 116987 [details] is in cell L1: if
> you want it as a label, it must be text not value.
> Solution:
> 1) move L1 outside your data range to sort, for instance AB1 (keep at least
> 1 empty column with your data),
> 2) enter a label in L1
> 3) click in a cell inside your data
> 4) Data > Sort
> "Range contains column labels" is ticked and criteria are remembered.
> 
> The behavior is the same with LibO 4.0.6. So, from my point of view there is
> no regression, no bug. Change status of the bug if you agree.

I put the value in cell Z1
I changed the formula in column L and gave it a text label.
I did the sort and saw that the 3 columns had been remembered but the Sort keys still showed the letters rather than the Labels and "Range contains column labels" refused to be remembered, so I have to go back to my original complaint that it used to work but no longer works and is a bug that needs to be fixed.

I'll believe you when you say you can get the correct results on your system.
But I can't get the same results. And I'm not trying to be difficult, I've been willing to try things that you've suggested but unfortunately none of the suggestions have been able to resolve the issue.

The fallback is simply that whenever I sort, I now have to go through an extra step to tick the "Range contains column labels" when before it wasn't necessary, now with the risk that should I forget, I then have to find the Label row and put it back at the row 1 again.

I thank you for your time, you've tried very hard and I appreciate that.
I just remain frustrated, I just can't fathom why a simple thing like a tick for "Range contains column labels" can't be remembered under every circumstance (when I don't change anything else.).

If, and that's a really big IF, there's now, with V4, a 'something else' that influences this behavior/issue, i.e. prevents it from being rememberd or auto unticks it when starting a sort, then again, that other something introduced a bug. Once I put a tick into a box, I expect that tick to be permanent until I remove it (which I'll never do).

These files were created in V3 and 'converted' to V4 if in fact there was a 'conversion' I didn't 'see' it.

As a final suggestion, can you take the time to test with V3? I was using V3.4.5 up until I installed V4.0.4 on 2013-06-23 which is when I discovered this issue. Of course that might not be possible due to other features added to LO, possibly conditional formatting and such, i.e. V3 might get very mixed up with a file from V4....  

Thanks,

but still a bug :), sorry.

(In reply to Aprax from comment #34)
> (In reply to Laurent BP from comment #33)
> > The problem with your document attachment 116987 [details] is in cell L1: if
> > you want it as a label, it must be text not value.
> > Solution:
> > 1) move L1 outside your data range to sort, for instance AB1 (keep at least
> > 1 empty column with your data),
> > 2) enter a label in L1
> > 3) click in a cell inside your data
> > 4) Data > Sort
> > "Range contains column labels" is ticked and criteria are remembered.
> > 
> > The behavior is the same with LibO 4.0.6. So, from my point of view there is
> > no regression, no bug. Change status of the bug if you agree.
> 
> I put the value in cell Z1
> ...

Please stop complaining and follow instructions above. I wrote 
> > 1) move L1 outside your data range to sort, for instance AB1 (keep at least
> > 1 empty column with your data),
If you put it in Z1 (instead of AB1 as I told you) then it is sticked with your data and Calc will include it in your data.

> As a final suggestion, can you take the time to test with V3? I was using 
> V3.4.5 up until I installed V4.0.4 on 2013-06-23 which is when I discovered
> this issue.
I installed LibO 3.4.6.2 and I agree with you: LibO keeps tick "Range contains column labels" even if first row contains values. The regression was introduced between 3.4.6.2 and 4.0.4.
Update version accordingly.

(In reply to Laurent BP from comment #35)
> (In reply to Aprax from comment #34)
> > (In reply to Laurent BP from comment #33)

> Please stop complaining and follow instructions above. I wrote 

> If you put it in Z1 (instead of AB1 as I told you) then it is sticked with
> your data and Calc will include it in your data.
> 
>
> I installed LibO 3.4.6.2 and I agree with you: LibO keeps tick "Range
> contains column labels" even if first row contains values. The regression
> was introduced between 3.4.6.2 and 4.0.4.
> Update version accordingly.

I forgot to say that I'd deleted the original column Z since it had some but no meaningful data and then I added the number 1.2500 to row 1 of column Z, so that was 'like' your suggestion to put it in column AB1.
What I didn't understand was that you'd picked AB1 because that left an entire column, AA completely empty. So I put it into AA1 with column Z entirely empty.

I agree now that by putting numerical constants in row 1 but with at least one empty column between that value and the 'real' data columns that the sheet does remember the Sort keys and the tick for "Range contains column labels".

That means that I'll have to go though all my spreadsheets and change the formulas to 'fit' the new 'format' or live with the workaround. All because someone made some change between V3 and V4.

So, again THANK YOU, I'm glad that you were willing to persevere until a 'solution' was found and one that I now understand. It's unfortunate where there are lots of constants leading to many more columns (plus a blank one :) ), since I change those values 'on-the-fly', an example being the currency exchange rate in the sheet that you've seen.

In the end: 
How many other folks have been doing what I was doing and have the problem? 
How will they discover the solution? 
It's unlikely to be found in the LO Help and not many will go looking through the 'bugs' list.

And I still think that it's a bug :)

Just a comment Laurent which certainly looks like I'm being picky, but

I see that you've changed the title to:

"Sorting setting Range contains column labels is forgotten if label contains values"

might be more aptly defined as:

"Sorting - The setting "Range contains column labels" is forgotten if any column Label contains a numeric value"

of course an even better one would be:

"Sorting - The setting "Range contains column labels" is forgotten if any column Label in row 1 contains a numeric value unless the value is moved to a row 1 cell with at least 1 empty column between the value and the data to be sorted"

Boggles the mind...

I'm going to be quiet now :)

Description: Sorting - The setting "Range contains column labels" is forgotten if any column Label in row 1 contains a numeric value (or an empty cell) unless the value is moved to a row 1 cell with at least 1 empty column between the value and the data to be sorted

Simplified procedure:
1) open attachment 116987 [details]
2) click inside data (for instance M5)
3) Data > Sort

Expected behavior:
Option "Range contains column labels" should be checked and criteria should contain labels

Actual behavior:
Criteria contain column letter.
Even checked and saved, option "Range contains column labels" is forgotten because cell L1 contains a numeric value (same apply with empty cell).

Works fine with LibO 3.4.6.2

@ Laurent: Great summary Laurent, thank you.

In order to help a coder who wishes to work on this I'd like to re-state the issue.

When a user defines a range of cells to be sorted and clicks through Data > Sort, the program performs a test of the contents of each cell in the first row of the Range. Note: "first row of the Range' need not be Row 1 although in most cases it will be.

1) If one or more numeric values are found, the program assumes that the first row does *not* contain column Labels and should be sorted with the other rows and it un-ticks the box for "Range contains column labels".

2) If no numeric values are found, the program assumes that the values are column Labels and ticks the box for "Range contains column labels".

This may be helpful upon the *very first sort* of the Range. However the user may realize that the auto-setting for the box for "Range contains column labels" is wrong for his/her purposes and changes the setting, runs the sort and Saves the sheet with the 'correct' setting expecting the setting to be saved for future sorts.

The issue is that the program performs the test *every* time that the sort process is run, not just the first time it's run, regardless of a saved user setting..

The best and probably easiest 'fix' would be to remove the test and leave it up to the user to choose.

But, if we *must* have the first row test, it should be restricted to the *first* time that the range is sorted, then: 
1) If the auto-setting is correct, the user need do nothing or 
2) If it's wrong, the user can change it. 
The setting should be saved and left "as is" for all subsequent sorts or until the user changes it.
======================================================
Scenarios where the program *assumption* is incorrect:
1) I define a range which contains only text, all rows are names and descriptions, there is no row containing Labels or numbers. 
The program assumes *incorrectly* that the first row must be a Label row.

2) I define a range which contains a number in the first row, e.g. in C$15 (an exchange rate to be used in calculations in the remaining rows). 
The program assumes *incorrectly* that the first row should be sorted with all other rows.

Just a note: this is only a problem with temporary intermediate sort ranges. If you actually really define a range via Data - > Define Range and tell that it has column headers then those are remembered and the problem goes away.

Just by selecting a range you do not define a range, it is just a selection that is used for an action. Though invoking Sort on some arbitrary selection could remember settings for the very same last range.

(In reply to Eike Rathke from comment #40)
> Just a note: this is only a problem with temporary intermediate sort ranges.
> If you actually really define a range via Data - > Define Range and tell
> that it has column headers then those are remembered and the problem goes
> away.
> 
> Just by selecting a range you do not define a range, it is just a selection
> that is used for an action. Though invoking Sort on some arbitrary selection
> could remember settings for the very same last range.

You are right, I did as you instructed and the settings are remembered.

The sequence for my purposes is to:
1) click the upper left corner to select the entire sheet
2) select Data > Define Range
3) key the name of the specific sheet in Name then click options and make sure that the box for "Contains column headers" is ticked, then click [Add] and 
4) verify that the range is the entire potential sheet even though not all cells have been populated, e.g. "$Wishlist.$A$1:$AMJ$1048576". Note the "To" values are the highest possible values.

My original point is still valid, someone changed something which worked to something which no longer worked AND the solution (yours) was non-intuitive. That means that others may be struggling with the issue and won't find the 'solution' unless they search the bug reports. 
I can't approve your solution as a 'fix' for the issue (though it's nice to have and I'll use it).

The offending change forces the box for "Range contains column labels" to *un-ticked* not only the first time someone selects a range which is less than the entire sheet but *every* time the sort is performed regardless of the selected range even after the user has set the desired *tick* and expects that to be saved.
I could live with the *un-ticking* the first time as long as it remembers my setting for subsequent sorts.

I suspect that one user submitted a request to suit only that one user.
The request was poorly conceived and implemented without any thought for potentially thousands of other users that would never want the request and were entirely happy with "the way it was" in version 3.

So, it's still a 'bug' until someone changes it to only perform it's function on the first time and not every time.

My comment wasn't meant as a fix but rather a suggestion for an improved workflow. Anyhow, I don't answer speculations, assumptions and accusations about who or who not requested or implemented whatever on bugs that contain more than 11 comments. Just to say that your tone is a bit, well, off and not much encouraging for those involved.

Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=33255f974fc712b9e9e2965a350c65a2195a7ae6

Resolves: tdf#88402 remember sort "has headers" at anonymous database ranges

It will be available in 5.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.

Pending review
https://gerrit.libreoffice.org/17136 for 5-0
https://gerrit.libreoffice.org/17140 for 4-0

Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e6241675a74e305b1af1049374be648ec63c37d8&h=libreoffice-5-0

Resolves: tdf#88402 remember sort "has headers" at anonymous database ranges

It will be available in 5.0.1.

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.

I'd be happy to test using Dailies, except that: 
I have a cellular IP and get billed rather heavily. Right now I'm close to a limit, if I go beyond that, it costs another $20CAD. Downloading the test Daily would put me over the limit. Maybe next 'month' which starts July 28th.

It is fixed with Version: 5.1.0.0.alpha1+
Build ID: 8cfdd81b70ef37927b40497ffd10034f28335034
TinderBox: Win-x86@39, Branch:master, Time: 2015-07-24_02:47:18
Locale: fr-FR (fr_FR)

You need to check "Range contains column labels" and save to keep it remembered.

Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5aecce00ee5e9c60cdd8a5af47600a06eddf911d&h=libreoffice-4-4

Resolves: tdf#88402 remember sort "has headers" at anonymous database ranges

It will be available in 4.4.6.

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.

Thank you Eike for pushing to 4.4.6 because 5.0.0.5 has HUGE issues with rendering, both in calc (I entered bug 93194)and writer (I didn't bother to enter a bug myself).
I'm going back to 4.4.6 for it's rendering stability.