Bug 130770

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. ***