Created attachment 92484 [details] Sample Spreadsheet that exhibits the faulty behavior This looks a lot like bug 66969, but that one is closed for good, so I opened another one, this time with my own Sample.ods. (Check that bug for the beginning of the discussion) I was checking 4.1.5 RC1 and it still exhibited almost the same faulty behavior: Just instead of the first two filter fields being forgotten, it's just the first one now. I reduced my spreadsheet to the bare minimums and attach it to this comment, same as the 'corrected' filter (how it looked, when I saved the file). Steps to reproduce: * Open the file PivotProblem.ods * refresh the Pivot Table in tab 'due' => Table collapses ==> Reason: The filter was not restored correctly when opening the file. The first 'field name' is actually the very first field in the source table, not the one that used to be in the filter when the file was saved. The saving seems to be OK though, since files I saved in 3.5+ were opened just fine (with the correct filter) in 3.4.x. Steps to resolve: * Open the Pivot-Filter (e.g. Double-Click on 'Filter') * Change the first 'Field Name' to "Eingang", like shown on the attached pic * Hit 'OK' => table is back Additional problem as described before (different bug?): * Try deselect values in the column filter (e.g. 'debitor') => the only ones you can de-select are the ones not present (e.g. 'empty') (You'll have to refresh the table, before you can do anything with the column filters, because internally the PT is actually 'empty' before you set the filter again to something including some data. It just displays the contents from the last save) I hope this helps narrow it down...
Created attachment 92485 [details] This is what the filter should look like after FILEOPEN
Hi Sebastian, thanks for reporting. For me the issue is that the first condition in the filter always return to the first field in the table after save and reopen. Verified with other spreadsheet. Win7x64Ultimate Versions checked with the issue. 3.5.7 4.1.6 4.2.0.2 Master. Open well with 3.3.4 so seems the issue is opening the file.
@Mario: I changed the bug caption to more accurately describe the error. Or should we say: 'First field name in filter get's reset to 1st fieldname of table after re-open' Anyway: from 3.5.x onward till lately (~2 weeks ago) it was the first *two* fieldnames (of the filter) that were reset to the 1st fieldname (of the table). I strongly suspect the patches for bug 66969 to (almost) fix this...
There are only 'skip'ped commits left to test. The first bad commit could be any of: 4851b756eb3b567f5dbae67af390d211e622e63c 67977e7d09cb355e3503197b66c680da12d42b2a bbc8a69d6517f9e77fd5e762e77c4b71117a4dc8 We cannot bisect more! git bisect log # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574 # bad: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15 git bisect bad 8f4aeaad2f65d656328a451154142bb82efa4327 # bad: [369369915d3582924b3d01c9b01167268ed38f3b] source-hash-45295f3cdceb4c289553791071b5d7f4962d2ec4 git bisect bad 369369915d3582924b3d01c9b01167268ed38f3b # bad: [351622aec2dff3cc3bbbb020ad0097c4322d2a21] source-hash-2c4537471c932b65e6f72e41881b505c4bbad12c git bisect bad 351622aec2dff3cc3bbbb020ad0097c4322d2a21 # good: [035c276ec5a8da669e6043a3db6b0701dd3c2ade] source-hash-dc8249af103741415a074d9bbf8b1211f24a7c3f git bisect good 035c276ec5a8da669e6043a3db6b0701dd3c2ade # bad: [d1cca78ab77d64482b6643bc643d29dbe2dd1442] source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4 git bisect bad d1cca78ab77d64482b6643bc643d29dbe2dd1442 # good: [bd61690e049a1941a9a555c391165d4cf7288e3b] source-hash-1ca547d20882e9b3d3ba9a6c7ee0340a5b7009b0 git bisect good bd61690e049a1941a9a555c391165d4cf7288e3b # skip: [4851b756eb3b567f5dbae67af390d211e622e63c] source-hash-71cbcb62028295a98ceee60cb4c4ee425bafcd2e git bisect skip 4851b756eb3b567f5dbae67af390d211e622e63c # bad: [bbc8a69d6517f9e77fd5e762e77c4b71117a4dc8] source-hash-5a212d501ee1c8ae2b7b9517a4ff486e61cac0fd git bisect bad bbc8a69d6517f9e77fd5e762e77c4b71117a4dc8 # skip: [67977e7d09cb355e3503197b66c680da12d42b2a] source-hash-a57304a53832adf0c8a32b0c53d9be5b55507ab1 git bisect skip 67977e7d09cb355e3503197b66c680da12d42b2a # good: [95db5447db1db95ce41dd3f1ad7d37bc3b44f1ed] source-hash-97453f1eabb473d0691e41153eff2ac92e88a302 git bisect good 95db5447db1db95ce41dd3f1ad7d37bc3b44f1ed # only skipped commits left to test # possible first bad commit: [bbc8a69d6517f9e77fd5e762e77c4b71117a4dc8] source-hash-5a212d501ee1c8ae2b7b9517a4ff486e61cac0fd # possible first bad commit: [4851b756eb3b567f5dbae67af390d211e622e63c] source-hash-71cbcb62028295a98ceee60cb4c4ee425bafcd2e # possible first bad commit: [67977e7d09cb355e3503197b66c680da12d42b2a] source-hash-a57304a53832adf0c8a32b0c53d9be5b55507ab1
Remove 'bisected' from Keyword as the commit that caused this regression hasn't been identified yet.
*** Bug 91412 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
This problem still exists in 5.0.5. All "Field Name" fields in Pivot Table "Filter Criteria" will be reset to 1st column in Pivot table range on reopen document.
This is bug is still present in 5.2.0.4 Filter is not retained after save-close-open
Regression introduced in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=97453f1eabb473d0691e41153eff2ac92e88a302..5a212d501ee1c8ae2b7b9517a4ff486e61cac0fd
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I'm still affected by this bug using Version: 6.1.3.2 Build ID: 1:6.1.3~rc2-0ubuntu0.18.04.2 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: fr-FR (en_GB.UTF-8); Calc: group threaded Filters resets itself to first column/field after reopening the file.
Still there in 6.3.3.2
still there in Version: 6.4.4.2 Build ID: 1:6.4.4~rc2-0ubuntu0.18.04.1
Still there in 7.0.3
Still there in Version: 7.1.0.1 (x64) Build ID: b585d7d90ab863bf29b2d110c174c0c2a98f3ee4 CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded
Still there in 7.1.0.3
still there in 7.2.1.2
still there in 7.3.1_rc3 :-(
Looks like regression from commit 5897d4a60f766ca0cd751281e7c32af3df677303.
Chenxiong Qi committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/26e3bfa02c4d582fd430171d509fa570ca364d35 tdf#73845 restore Empty and NonEmpty query filter after FILEOPEN It will be available in 7.5.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.
Chenxiong Qi committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/20c7fbad7d929df335b0610a748b6e1d694dafaf tdf#73845 restore Empty and NonEmpty query filter after FILEOPEN It will be available in 7.4.2. 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.
Yay!!! Looks good in Version: 7.4.2.1 (x64) / LibreOffice Community Build ID: 681d65acd9ede00dd724d6716f21cabfdcc95bd2 CPU threads: 8; OS: Windows 10.0 Build 22623; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded Took a long time, but got there. Thanks Sebastian
Sounds like we can change status to fixed
Fixed in 7.4.2.3 (linux mint 21) Thanks a lot