Created attachment 147747 [details] Sheet document in 3 states In a sheet document I have filtered rows by Autofilter on several columns and then I have cleared all Autofilters one after the other (set to "All"). Result: Not all rows of the sheet were displayed. Steps to reproduce: 1. open "Test_Autofilter_V3_no_filters_active.ods" from attached zip file 2. set autofilters: - column A (Modell): select only "Tenax" - column G (Sucher): select only "Klappsucher" - column H (Spaannhebel): select only "Unterteil Blech" 3. reset autofilters: - column G (Sucher): set to "All" (only 1 item in the list) --> filter arrow remains blue - column A (Modell): set to "All" (only 1 item in the list) --> filter arrow - column H (Spannhebel): set to "All" --> filter arrow blue Actual result: All autofilters are set to "All", but not all rows are displayed, see attached document "Test_Autofilter_V3_all_Autofilters_are_set_to_all.ods". Expected result: All rows are displayed. Further check on all autofilters with black filter arrows (not activated until now): All are set to "All", see attached document "Test_Autofilter_V3_all_Autofilters_are_set_to_all.ods" The only way I have found to clear the filters and show all rows is select "standard filter" on any column with blue filter arrow and set field name in the first line to "- none -". Tested with Version: 6.2.0.1 (x64) Build-ID: 0412ee99e862f384c1106d0841a950c4cfaa9df1 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded
Thank you for reporting the bug. I can confirm that the bug is present in Version: 6.3.0.0.alpha0+ Build ID: 3c964980da07892a02d5ac721d80558c459532d0 CPU threads: 2; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2018-12-12_02:07:45 Locale: en-US (en_US); UI-Language: en-US Calc: threaded
Created attachment 147903 [details] Reproduction of AutoFilter issue I can confirm this bug in 6.2.0.1-rc. My assumption is that it has to do with the count of the different unique values. Just a guess. Reproduction with attached file "AutoFilter_Issue_6.2.0.1-rc.ods" * Filter Col B to #N/A (so that TRUE is filtered out) * Filter Col A to any value you like * Filter Col A back to All * Result: Filter Col B cannot be set back to all values, as TRUE is missing in the filter list
Still an issue in latest rc 6.2.0.2
Also reproducible on recent master: Version: 6.3.0.0.alpha0+ (x64) Build ID: 423d70f7e45749fad680b3dfe0ccdaed1c1afb19 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-01-14_23:07:06 Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded
Not reproduced in Version: 5.4.0.0.alpha1+ Build ID: 9feb7f7039a3b59974cbf266922177e961a52dd1 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group -> regression
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=c8a739a2c84f45f878d2ae75eaf16a2f814d1c6e author Serge Krot <Serge.Krot@cib.de> 2018-06-07 18:02:50 +0200 committer Katarina Behrens <Katarina.Behrens@cib.de> 2018-06-12 16:09:33 +0200 commit c8a739a2c84f45f878d2ae75eaf16a2f814d1c6e (patch) tree 034a7a24a6eb90d7a9e9e3c3523bf068092621ec parent df652aa70869f42ada2f4d8e7d1cacf55c6e6e96 (diff) tdf#117276 filter reset: check complete data range selected Bisected with: bibisect-linux64-6.2 Adding Cc: to Serge Krot
Quick fix with unit test is available here: https://gerrit.libreoffice.org/#/c/67001/
Serge Krot committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/fb3c3216ba1a6fc978176eebcef0cab4599a39e7%5E%21 tdf#122260 sc: Autofilters not properly cleared It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tested as described in the bug report with Version: 6.3.0.0.alpha0+ (x64) Build ID: fa6d726a9369fd49ff2b6c00da682641a025ba50 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-01-30_23:24:34 Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded Result: Test OK! All filters are reset correctly.
Will the bug also be fixed in LO 6.2.1?
I request that this should even go into 6.2.0-rc3.
That would be even better, but I'm afraid it's too late for that: 6.2.0-rc3 was released one week ago (25.01.2019) and the release of 6.2.0 is planned for the coming week 6 , Feb 4, 2019 - Feb 10, 2019.
6.2.0-rc3 is not available on https://www.libreoffice.org/download/pre-releases/
On the linked location it isn't described but when you click on "Access the Pre-releases server and pick the version of your choice there." you can navigate to the folder you need and you will find the files for LO 6.2.0.3 - and only in the folder Win/x86_64/ already also LibreOffice_6.2.1.0.0_Win_x64.msi (?).
Serge Krot committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/eb2d8e088fef630bd16fea3317a6ac74ebd2f3ce%5E%21 tdf#122260 sc: Autofilters not properly cleared It will be available in 6.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
How shall users know about a new RC if this is not announced on the webpage? Of course there are only a few bug reports on RC3, when nobody tests it. Also I wouldn't release it with a highly reproducable Clipboard Copy Hang/Crash on Windows, see bug 122435. But that's all up to the dev team.
Verified in Version: 6.3.0.0.alpha0+ Build ID: 1204af25fde368cfd3539915dc6cc4edcecec041 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Serge Krot, thanks for fixing this!!
(In reply to Maddes from comment #16) > How shall users know about a new RC if this is not announced on the webpage? > Of course there are only a few bug reports on RC3, when nobody tests it. > > Also I wouldn't release it with a highly reproducable Clipboard Copy > Hang/Crash on Windows, see bug 122435. But that's all up to the dev team. We announced it in the QA blog -> https://qa.blog.documentfoundation.org/2019/02/01/libreoffice-6-2-rc3-is-ready-for-testing/
Tested as described in the bug report with Version: 6.2.1.0.0+ (x64) Build ID: b0b203b5d09054250a257c052d7c7870eb1c4ffe CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:libreoffice-6-2, Time: 2019-02-04_15:23:13 Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded Result: Test OK! All filters are reset correctly.
*** Bug 122496 has been marked as a duplicate of this bug. ***