Download it now!
Bug 130770 - Autofilter not updated on data change (automatically or manually)
Summary: Autofilter not updated on data change (automatically or manually)
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.3.4.2 release
Hardware: x86-64 (AMD64) All
: high major
Assignee: Scito
URL:
Whiteboard: target:7.0.0 target:6.4.5
Keywords: bibisected, bisected, needsUXEval, regression
: 131095 131612 132690 (view as bug list)
Depends on:
Blocks: AutoFilter
  Show dependency treegraph
 
Reported: 2020-02-19 09:26 UTC by thatho
Modified: 2020-07-18 06:05 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description thatho 2020-02-19 09:26:24 UTC
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
Comment 1 Julien Nabet 2020-02-19 09:45:45 UTC
On Win10 with LO 6.3.4.2, I could reproduce this.
Comment 2 Roman Kuznetsov 2020-02-19 09:59:42 UTC
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
Comment 3 danitxu 2020-02-22 10:56:23 UTC
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.
Comment 4 raal 2020-02-24 22:10:09 UTC
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 sha: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
Comment 5 Julien Nabet 2020-03-03 16:33:33 UTC
*** Bug 131095 has been marked as a duplicate of this bug. ***
Comment 6 Julien Nabet 2020-03-26 22:45:14 UTC
*** Bug 131612 has been marked as a duplicate of this bug. ***
Comment 7 Julien Nabet 2020-04-03 15:15:51 UTC
Let's put ASSIGNED then.
Comment 8 Scito 2020-04-03 15:27:15 UTC
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.
Comment 9 Commit Notification 2020-04-29 15:22:06 UTC
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.
Comment 10 Scito 2020-05-13 06:22:50 UTC
The commit fixed this issue. So, I'm marking this issue as fixed.
Comment 11 b. 2020-05-17 16:33:04 UTC
*** Bug 132690 has been marked as a duplicate of this bug. ***
Comment 12 Xisco Faulí 2020-05-19 19:51:53 UTC
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
Comment 13 p_kongstad 2020-05-20 07:40:27 UTC
Hopefully this fix will also be in 6.3 and 6.4.
Comment 14 Aron Budea 2020-05-20 12:19:42 UTC
(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?
Comment 15 Xisco Faulí 2020-05-20 13:20:23 UTC
(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
Comment 16 Commit Notification 2020-05-20 14:24:33 UTC
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.
Comment 17 Scito 2020-05-21 12:09:06 UTC
(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.
Comment 18 b. 2020-07-18 06:05:24 UTC
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 ...