Description: SF & AF work always case sensitive. Checking/unchecking the 'Case sensitive' checkbox does not matter. Steps to Reproduce: 1. Open Standard/Advanced filter dialog. 2. Check or uncheck 'Case sensitive' checkbox one at a time. Do other work. 3. Apply a filter. Compare the result. Actual Results: The data will always be case sensitive. Expected Results: There should be no extra data that differs only in the case of characters. Reproducible: Always User Profile Reset: No Additional Info: A sample file is attached. Version: 7.2.0.4 / LibreOffice Community Build ID: fa0a9af5681a0acc7909a705f92c1ada8a658552 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: ru-RU (ru_RU.UTF-8); UI: en-US Calc: threaded
Created attachment 174650 [details] Demo file with filtering error The sample file contains the data needed to reproduce the error. The custom utility correctly performs the case-insensitive duplicate removal task.
here is an ambiguity in the feature description that doesn't allow to clearly see if this is a bug or not. The question assumes that "Case sensitive" option of the filters applies to the "No duplications"; but help [1] does not state that; it only tells that (1) Case sensitive "Distinguishes between uppercase and lowercase letters when filtering the data", and (2) No duplication "Excludes duplicate rows in the list of filtered data". So the (1) is only said to apply to the filtering conditions - not to duplication finding? On one hand, this may be seen as "works as designed"; on the other hand, it's likely that users would expect the different behavior. It's interesting what other spreadsheet applications do in this case. Adding Eike to CC; also asking advice of UX team. [1] https://help.libreoffice.org/7.2/en-US/text/scalc/01/12040201.html?&DbPAR=CALC
Excel AdvancedFilter filters unique data case insensitively, including Cyrillic. And the option corresponding to "Case sensitive" is not there. However, numeric data is distinguished as numbers and strings (?).
Quite obvious to me since the list of items shows only lowercase (Foo, foo = foo) unless I check the sensitive option (only for SF). Would not increase the complexity of the AF but just add a note to the documentation.
No further opinion, recommend to resolve WF (and add it to documentation). The standard filter provides means to run case sensitive and adding the option to the auto filter would clutter the widget further. (In reply to Mike Kaganski from comment #2) > Adding Eike to CC Please reopen in case you disagree.
(In reply to Heiko Tietze from comment #5) > The standard filter provides means to run case sensitive and adding the > option to the auto filter would clutter the widget further. IMHO that's not what is requested.. the original description lacks the mention of "No duplication" that seems to be the actual problem here, which becomes (somewhat) clearer when opening the sample document (which is confusing enough though). I'd rather expect that when filtering is done case insensitive that also uniqueness (no duplication) is case insensitive. Doing so also wouldn't need any new option in the dialog. Reopening.
Test: "AAA", "aaa", "BBB", "bbb", "AAA" Current behavior when sorting "Test" = "not empty" with the options [x] No duplication & [ ] Case sensitive = "AAA", "aaa", "BBB", "bbb" [x] No duplication & [x] Case sensitive = "AAA", "aaa", "BBB", "bbb" Expected behavior: [x] No duplication & [ ] Case sensitive = "AAA", "BBB" [x] No duplication & [x] Case sensitive = "AAA", "aaa", "BBB", "bbb"
Created attachment 176687 [details] for testing I have attached a simple file in order to test the bug, as mentioned by Heiko. In order to test: just check No duplication, then Check or Uncheck "Case sensitive": not working.
Dear Igor, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug