Description: When filter is applied on a column and data is changed by EDITING (manually), the filter does not update. Update by F9 (recalculate) does not update filter either. Steps to Reproduce: 1. create data two columns term1 term2 a 0 b 1 a 1 b 0 2. apply autofilter on data header (1st row) 3. filter second column by 1 ([ ]0 [x]1) Result: term1 term2 b 1 a 1 4. edit any of the "1" to "0" term1 term2 b 1 a 0 Result: no change in the applied filter. I have to says, that this behavior is very fine, because the user is given an opportunity to check on changes. 5. Recalculate (by F9) no change: term1 term2 b 1 a 0 expected result: term1 term2 b 1 7. open filter dialog to the 2nd column and confirm the settings by pressing "OK" no change: term1 term2 b 1 a 0 expected result: term1 term2 b 1 Actual Results: The filter does not update data columns on "Recalculate" or "confirming the filter settings by OK". Expected Results: The filter should update the data columns on "Recalculate" and(!) "confirming the filter settings by OK", both. Reproducible: Always User Profile Reset: No Additional Info: Version: 6.4.0.3 (x64) Build ID: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8 CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; Locale: cs-CZ (cs_CZ); UI-Language: en-US Calc: threaded
On Win10 with LO 6.3.4.2, I could reproduce this.
confirm this behavior in Версия: 7.0.0.0.alpha0+ (x64) ID сборки: 41177730421f9be9ad955766a5a19667d8003b11 Потоков ЦП: 4; ОС: Windows 10.0 Build 18362; Отрисовка ИП: по умолчанию; VCL: win; Локаль: ru-RU (ru_RU); Язык интерфейса: ru-RU Calc: threaded I'm not sure about updating Autofilter with Recalculate (F9), but really the problem is not updating Autofilter manually after 1. Filter by 1 2. Change value 1 to 0 3. Open Autofilter 4. Press OK (because Autofilter already has selected only value 1!) 5. Nothing happens you should open Autofilter, select "All", press OK, then open Autofilter again, select only 1, then press OK. it works as I expected in 6.2 but not in 6.3 => it's a regression
Confirmed also on LibreOffice Calc 6.3.4.2 with Kubuntu (GNU/Linux). Also I've verified this sequence: * (With a filter applied, we change a value in the spreadsheet to change the filtering result) * Open Autofilter * From "Autofilter" dialog click on "Standard filter" to open this dialog * Click on OK Then the result is what is expected to be. Even though this solves the problem, it should be convenient to make the right behavior without having to open "Standard filter" dialog from "Autofilter" dialog.
This seems to have begun at the below commit. Adding Cc: to Serge Krot ; Could you possibly take a look at this one? Thanks 31fbd00c6bccdffb921ec74f745d775e15d105be is the first bad commit commit 31fbd00c6bccdffb921ec74f745d775e15d105be Author: Jenkins Build User <tdf@pollux.tdf> Date: Fri Apr 12 20:22:22 2019 +0200 source 4e7e3670c31329d60f5cc782abc4568c2aba33a7 author Serge Krot <Serge.Krot@cib.de> 2019-03-05 17:03:31 +0100 committer Thorsten Behrens <Thorsten.Behrens@CIB.de> 2019-04-12 11:46:58 +0200 commit 4e7e3670c31329d60f5cc782abc4568c2aba33a7 (patch) tree 0e962c50607a049634400d32c0d96871427c9fc9 parent 0342562261beede5d3bb2e43c08f6d0f216ff97c (diff) tdf#117276 sc: autofilter was unexpected reset with OK pressed
*** Bug 131095 has been marked as a duplicate of this bug. ***
*** Bug 131612 has been marked as a duplicate of this bug. ***
Let's put ASSIGNED then.
I have analyzed and found the problem. The following code checks for changes in the autofilter itself and returns if the autofilter itself did not change. This code leads to this issue. Note: Standard autofilter with values has AutoFilterMode::Normal mode. if (eMode != AutoFilterMode::Top10 && eMode != AutoFilterMode::Empty && eMode != AutoFilterMode::NonEmpty) { // do not recreate auto-filter rules if there is no any changes from the user ScCheckListMenuWindow::ResultType aResult; mpAutoFilterPopup->getResult(aResult); if (aResult == aSaveAutoFilterResult) { SAL_INFO("sc.ui", "nothing to do when autofilter entries are the same"); return; } } I've submitted a patch.
scito committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e9c04fdc6d91a152c9197bda3b07316bed1dc4f3 tdf#130770 apply autofilter to data regardless of autofilter changes It will be available in 7.0.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.
The commit fixed this issue. So, I'm marking this issue as fixed.
*** Bug 132690 has been marked as a duplicate of this bug. ***
Verified in Version: 7.0.0.0.alpha1+ Build ID: 8209c2569f5726f9ed29f75d30efdccb94f98fe5 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @scito, thanks for fixing this issue! Increasing importance based on number of duplicates Backported to 6-4 branch in https://gerrit.libreoffice.org/c/core/+/94457
Hopefully this fix will also be in 6.3 and 6.4.
(In reply to p_kongstad from comment #13) > Hopefully this fix will also be in 6.3 and 6.4. As mentioned above, backport to 6.4 is already in gerrit. Scito, Xisco what are your thoughts on a 6.3 backport?
(In reply to Aron Budea from comment #14) > (In reply to p_kongstad from comment #13) > > Hopefully this fix will also be in 6.3 and 6.4. > As mentioned above, backport to 6.4 is already in gerrit. > Scito, Xisco what are your thoughts on a 6.3 backport? Too late for 6.3. It's reaching End of Life on May 29, 2020
scito committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/ef3cf9e46d489349f3c8fcbf38e01526961a0a30 tdf#130770 apply autofilter to data regardless of autofilter changes It will be available in 6.4.5. 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.
(In reply to Xisco Faulí from comment #12) > Increasing importance based on number of duplicates > Backported to 6-4 branch in https://gerrit.libreoffice.org/c/core/+/94457 Cool, thank you.
partly fixed, issue left, re-applying filter recalculates - ok, F9 doesn't recalculate - F9 is 'cell specific'? which cells should be 'hot' to trigger? imho header and changed cell would qualify, ctrl-shift-F9 doesn't recalculate - imho clear bug, 'recalculates all' isn't fulfilled, what to do? leave as is? reopen bug? new bug? needs senior advice, btw.: don't get used to use 'hard-recalc' as standard use, it's an analysis too to check if something went wrong, normal use should go without, if you use hard recalc as standard use there is no analysis tool anymore ...
Because of previous comment: I consider this bug fixed. Help for Recalculate says it's for formulas, filter is not mentioned.
*** Bug 133492 has been marked as a duplicate of this bug. ***