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
Created attachment 181160 [details] Simple Spreadsheet for Standard Filter Bug
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
(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.
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
Dear bugfree, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear bugfree, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp
(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
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
(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.
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.
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) 👍
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" 😥!
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?!
Was still ok for me with Version: 6.0.7.3 (x64) Build-ID: dc89aa7a9eabfd848af146d5086077aeed2ae4a5 Which still had the old filter ID
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
@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
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
*** Bug 149098 has been marked as a duplicate of this bug. ***
(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.
*** Bug 158509 has been marked as a duplicate of this bug. ***