I have a problem with sorting when I use autofilter ascending with Calc. It gives me something different from the order given by a unix ls command (Unicode order): > ls -1 aaa2004 aaa_2005 aaa_2006 Calc with an autofilter set on ascending order gives me: aaa_2005 aaa_2006 aaa2004 Reported at: https://ask.libreoffice.org/en/question/58253/autofilter-with-ascending-gives-a-different-order-from-unix/
Setting to NEW as A. Kemp reproduced in the AskLibO page.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20161108
Dear PBrockmann, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Reproduced in: Version: 7.2.0.0.alpha1+ / LibreOffice Community Build ID: bb54d6d8241a06a6772052b77b67d6a4f686426c CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-06-11_20:14:38 Calc: threaded
There is a bug here, but it's not what the OP thinks it is. The bug is: autofilter overwrites the sort range's descriptor. The OP wants the natural sort order, but that's not available through autofilter. So we sort the range with options and then add Autofilter. The problem is that Autofilter, when actually applied, overwrites the sort order option set in the sort range's descriptor. 1) Open a new Calc document and enter the OP's data into a column of cells along with a heading row of "data", but we scramble the data a bit to confirm that the sort is happening. Our cell contents are: data aaa2004 aaa_2006 aaa_2005 2) Select the range including the heading and sort it with options: 2a) Select the range including the title 2b) Choose Data menu > Sort... 2c) Choose Sort dialog Options tab 2d) Check "Range includes column labels" 2e) Check "Enable natural sort" 2f) Click OK The data is now sorted as the OP wants. Our cell contents are: data aaa2004 aaa_2005 aaa_2006 3) With the range still selected, choose Data menu > Autofilter Autofilter sees that the range has a column heading set by the sort range's descriptor and does not ask whether to use the first row as a heading. This is good. The range's heading cell now acquires the Autofilter dropdown menu button, but nothing will happen to the data until the Autofilter option is exercised, which we will do in step 5. 4) With the range still selected, confirm that sort options are still set. 2a) Choose Data menu > Sort... 2b) Choose Sort dialog Options tab 2c) See that the column labels and natural sort options are still checked 2d) Click Cancel 5) Sort the range using the Autofilter's dropdown menu button in the heading. 5a) Click the downward pointing triangle in the heading cell 5b) Click Sort Ascending Notice that the data is now sorted as the OP's complains, not the natural order. 6) With the heading row still selected, verify sort options once again. 6a) Choose Data menu > Sort... 6b) Choose Sort dialog Options tab 6c) See that the column label is still checked but the natural sort is now unchecked. 2d) Click Cancel Step 6 shows that the Autofilter sorting action overwrites the sort descriptor. The Sort Ascending and Sort Descending UI buttons and corresponding menu options are even more egregious, wiping out the entire sort descriptor including the column heading. Is this by design? I think not. As far as the default sort order, I find no fault in LO Calc's choice. Unicode Technical Standard #10 UNICODE COLLATION ALGORITHM https://www.unicode.org/reports/tr10/ declares as the basic principle: "The position of characters in the Unicode code charts does not specify their sort order." The meaning of "Unicode order" is thus utterly ambiguous because code points collate in different orders for different languages. However, taking the cue of "unix ls" as the OP's desired sort order, the "Enable natural sort" option should be selected by the OP. The default sort order used by LO is in fact the start of the Unicode code set, where the first 127 characters copies the 7-bit ASCII code: punctuation precedes digits which precedes alphabetic characters.