Bug 149907 - Standard Filter demands change on "Value" field, otherwise it does not update results
Summary: Standard Filter demands change on "Value" field, otherwise it does not update...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.3.4.2 release
Hardware: x86-64 (AMD64) All
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 149098 158509 (view as bug list)
Depends on:
Blocks: AutoFilter
  Show dependency treegraph
 
Reported: 2022-07-08 03:42 UTC by bugfree
Modified: 2024-06-01 01:31 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
Simple Spreadsheet for Standard Filter Bug (17.22 KB, application/vnd.oasis.opendocument.spreadsheet)
2022-07-08 03:43 UTC, bugfree
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bugfree 2022-07-08 03:42:08 UTC
Description:
The "Condition" on the "Standard Filter" can not be updated after it has been added. Once it is set, you can change it but it does not apply the new "Condition".

Steps to Reproduce:
1. Highlight first row in a set of data
2. Click Data > Auto Filter (to turn Auto Filter on)
3. Click the drop down arrow on any column
4. Click "Standard Filter"
5. Select a "Condition" and "Value" and click OK
6. The filter is displayed correctly.
7. Now go back into the "Standard Filter" and update the "Condition" and click OK. The "Condition" appears to change visually but it does not update in the spreadsheet.


Actual Results:
The "Condition" is not be updated. If you go back into the "Standard Filter" you will see that the "Condition" has not changed.

Expected Results:
The "Condition" should be updated to the new "Condition" which is selected.


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.3.4.2 / LibreOffice Community
Build ID: 30(Build:2)
CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Ubuntu package version: 1:7.3.4-0ubuntu0.22.04.1
Calc: threaded
Comment 1 bugfree 2022-07-08 03:43:15 UTC
Created attachment 181160 [details]
Simple Spreadsheet for Standard Filter Bug
Comment 2 m_a_riosv 2022-07-09 07:38:06 UTC
I can't reproduce.
Version: 7.3.5.1 (x64) / LibreOffice Community
Build ID: d56c1c78db15939340c3db8ee3b6667832313d23
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US Calc: CL

Please test with a clean profile, Menu/Help/Restart in Safe Mode
Comment 3 bugfree 2022-07-11 03:59:37 UTC
(In reply to m.a.riosv from comment #2)
> I can't reproduce.
> Version: 7.3.5.1 (x64) / LibreOffice Community
> Build ID: d56c1c78db15939340c3db8ee3b6667832313d23
> CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL:
> win
> Locale: es-ES (es_ES); UI: en-US Calc: CL
> 
> Please test with a clean profile, Menu/Help/Restart in Safe Mode

Same problem with a clean factory reset profile unfortunately.
Comment 4 LeroyG 2022-07-11 19:49:28 UTC
NO reproducible with:
Version: 7.2.3.2 / LibreOffice Community
Build ID: 20(Build:2)
CPU threads: 1; OS: Linux 5.3; UI render: default; VCL: gtk3
Locale: es-MX (es_ES.UTF-8); UI: en-US
Calc: threaded
Comment 5 QA Administrators 2023-01-08 03:23:49 UTC Comment hidden (obsolete)
Comment 6 QA Administrators 2023-02-08 03:24:53 UTC Comment hidden (obsolete)
Comment 7 ady 2023-02-09 06:48:04 UTC
(In reply to bugfree from comment #0)
> Steps to Reproduce:
> 1. Highlight first row in a set of data
> 2. Click Data > Auto Filter (to turn Auto Filter on)
> 3. Click the drop down arrow on any column
> 4. Click "Standard Filter"
> 5. Select a "Condition" and "Value" and click OK
> 6. The filter is displayed correctly.
> 7. Now go back into the "Standard Filter" and update the "Condition" and
> click OK. The "Condition" appears to change visually but it does not update
> in the spreadsheet.

Since others posted that they cannot repro, I am describing in detail exactly what I did.

Using attachment 181160 [details] from comment 1 posted by the OP, and following the above steps, I selected the autofilter for column D "Height (cm)", "Filter By Condition", "Standard Filter". In the Condition field I used "<", in the Value field I used "3", then OK.

The list was filtered using this first condition (2 rows and the first labels' row).

As the "Steps to Reproduce" say, I went back to "Filter By Condition", "Standard Filter". In the Condition field I changed it from "<" to "=", in the Value field I still used "3", then OK.

The resulting list was _not_ updated.

Let's add a couple more steps. Change both fields, Condition to ">" and Value to "4", then OK. => The resulting list was indeed updated.

Now again change _only_ the Condition field (without even touching the Value field) from ">" to "<" (or to "=").

The resulting list was _not_ updated.

Just in case, I also PageDown, PageUp, to refresh the screen.

Additional observation: after the list seems to be not updated, when going back to the "Condition" field in the "Standard Filter" the "Condition" doesn't show the very latest condition that was introduced, but rather the previous one. IOW, it's as if the modification of the "Condition" field was not really performed, just because the “Value” field was not modified too (whereas the user certainly did change the former).

Conclusion:

* If _only_ the "Condition" field is modified in the Standard Filter, then the resulting list (of filtered rows) is _not_ updated.

* An alternative way of expressing it (possibly more accurate): if the "Value" field is left unchanged, then the resulting list is not updated according to the newly modified "Condition" field.

Repro in:

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: d8e6b488ceaff7c88856ebcfcfec14d2d8cd7652
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: en-US (es_AR); UI: en-US
Calc: CL threaded
Comment 8 m_a_riosv 2023-02-09 20:43:23 UTC
I can reproduce now. Seems that without re-select the value, the condition it's not changed. Changing only the condition doesn't trigger that there is a modification.
Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 9d44236a62bf59d120dda89924d0d1407b2bd52b
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Jumbo
Comment 9 ady 2023-02-10 10:30:22 UTC
(In reply to m.a.riosv from comment #8)
> Seems that without re-select the value, the condition
> it's not changed. Changing only the condition doesn't trigger that there is
> a modification.

In my experience posted in comment 7, it was not enough to just re-select the Value field. If you just re-select the _same_ value as it was before, the modified Condition is not reflected in the resulting list either. You must change the Value field in some way, whereas the Condition field can be either left the same or modified. IOW, the resulting filtered list depends on performing some modification to the Value field, in order to get actually updated.
Comment 10 Rainer Bielefeld Retired 2023-02-25 13:12:01 UTC
REPRODUCIBLE with Installation of Version: 7.5.0.1 (X86_64)  
Build ID: 77cd3d7ad4445740a0c6cf977992dafd8ebad8df
CPU threads: 12; OS: Windows 10.0 Build 19044; 
UI render: default; VCL: win – Locale: de-DE (de_DE); UI: de-DE
Calc: threaded |  Elementary (SVG)  Theme  |  Normal UserProfile 

And it's worse than "normal"

To be honest, I am not 100% sure whether my observation is exactly this one or Bug 149098 - Changing Standard Filter condition does not work unless you also update the value or something else related. 
I will create a simple sample from my real life spreadsheet and attach it later in the afternoon.
Comment 11 Rainer Bielefeld Retired 2023-02-25 15:16:30 UTC
NOT reproducible for me with above mentioned LibO version and " Simple Spreadsheet for Standard Filter Bug 2022-07-08 03:43 UTC, bugfree ":
1. open file
2. ˋFilter-▼ for column ID → Filter for Condition → Standard Filter → 
   ID bigger than 123460 (typen manually) → AND ID smaller than 123465 → 
   [ok]ˊ   👍 
   » As expected shows 123461 ... 123464)
3. ˋFilter-▼ for column ID → Filter for Condition → Standard Filter → 
   modify 123465  to  123466 (type manually)  → [ok]ˊ 
   » As expected shows 123461 ... 123465)   👍
Comment 12 Rainer Bielefeld Retired 2023-02-25 15:59:18 UTC
But REPRODUCIBLE for me with above mentioned LibO version and " Simple Spreadsheet for Standard Filter Bug 2022-07-08 03:43 UTC, bugfree ":
1. open file
2. ˋFilter-▼ for column ID → Filter for Condition → Standard Filter → 
   ID bigger than 123460 (typen manually) → AND ID smaller than 123465 → 
   [ok]ˊ   👍 
   » As expected shows 123461 ... 123464)
3. ˋFilter-▼ for column ID → Filter for Condition → Standard Filter → 
   modify ">" to  ">="  → modify "<> to "<="  → [ok]ˊ 
   » Expected shows 123460to 123465
    Actual: shown range still "123461 ... 123464" 😥!
Comment 13 Rainer Bielefeld Retired 2023-02-25 16:04:33 UTC
Looking into the Standard filter again shows that the modified filter condition has not been hold after [ok], you will see the old filter condition operator.

And indeed, as "Bug 149098 - Changing Standard Filter condition does not work unless you also update the value" heals the problem (for the operator in that line).

So I think this one can me marked as DUP of 149098?!
Comment 14 Rainer Bielefeld Retired 2023-02-25 16:13:35 UTC
Was still ok for me with Version: 6.0.7.3 (x64)
Build-ID: dc89aa7a9eabfd848af146d5086077aeed2ae4a5
Which still had the old filter ID
Comment 15 Rainer Bielefeld Retired 2023-02-25 16:29:14 UTC
And indeed, was still ok for me until 
Version: 7.2.5.2 (x64) / LibreOffice Community
Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5
CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: default; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: CL
Comment 16 ady 2023-02-25 23:47:24 UTC
@Rainer, most of the info is/was already posted in comment 7 and in the "see also" field.

Currently this is repro since LO 7.3 up until current 7.6 alpha+.

From the release notes for LO 7.3 (see [1]), there are at least 3 items related to filtering features in Calc (i.e. potential suspects for origin of regression):

* Support Color Filter in "Standard Filter" dialog tdf#143103 (Samuel Mehrbrodt, allotropia)

* Queries and filters using some text-based operations such as 'contains' now properly work even with numeric data core commit 0d1971a8 (Luboš Luňák, Collabora)

* Improved speed for filtering by Autofilter tdf#133835, tdf#133867, tdf#133996 (Noel Grandin, Luboš Luňák, Collabora)

[1]: https://wiki.documentfoundation.org/ReleaseNotes/7.3#Calc
Comment 17 Kira Tubo 2023-09-17 05:27:49 UTC
Bibisected win64-7.3. 

Regression is occurring at: https://git.libreoffice.org/core/+/d9dd003f63a781e63bfbe380ea737e080c21881f

commit d9dd003f63a781e63bfbe380ea737e080c21881f	[log]
author	Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>	Thu Sep 09 09:33:49 2021 +0200
committer	Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>	Thu Sep 16 16:21:19 2021 +0200
tree 35defd81fdfb99b6254f8d5011fe3dd42297d248
parent 40f38fd16dad4374543d4a7a109b3264837ce8d1 [diff]
 f214ddfa292237d3c76f9ae6b3d894f296472d5e is the first bad commit
commit f214ddfa292237d3c76f9ae6b3d894f296472d5e
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Thu Sep 16 08:17:55 2021 -0700

    source d9dd003f63a781e63bfbe380ea737e080c21881f
Comment 18 Kira Tubo 2023-09-17 06:05:42 UTC
*** Bug 149098 has been marked as a duplicate of this bug. ***
Comment 19 ady 2023-09-17 06:15:11 UTC
(In reply to Kira Tubo from comment #17)
> Bibisected win64-7.3. 
> 
> Regression is occurring at:
> https://git.libreoffice.org/core/+/d9dd003f63a781e63bfbe380ea737e080c21881f

That would be a regression caused by:
Support Color Filter in "Standard Filter" dialog tdf#143103 (Samuel Mehrbrodt, allotropia)

CC'ing Samuel.
Comment 20 ady 2023-12-04 20:01:54 UTC
*** Bug 158509 has been marked as a duplicate of this bug. ***
Comment 21 pavelz 2024-05-17 16:02:40 UTC
Still reproducible in
Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 658a212585c56540a17c41111e6829716d4ef4e3
CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded