Bug 73845 - PIVOTTABLE: Filter incorrectly restored after FILEOPEN
Summary: PIVOTTABLE: Filter incorrectly restored after FILEOPEN
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.5 all versions
Hardware: Other All
: medium normal
Assignee: qcxhome
URL:
Whiteboard: target:7.5.0 target:7.4.2
Keywords: bibisected, regression
: 91412 (view as bug list)
Depends on:
Blocks: Pivot-Table
  Show dependency treegraph
 
Reported: 2014-01-20 20:03 UTC by Sebastian Goetze
Modified: 2022-10-14 20:57 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample Spreadsheet that exhibits the faulty behavior (123.81 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-01-20 20:03 UTC, Sebastian Goetze
Details
This is what the filter should look like after FILEOPEN (4.43 KB, image/png)
2014-01-20 20:04 UTC, Sebastian Goetze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Goetze 2014-01-20 20:03:06 UTC
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...
Comment 1 Sebastian Goetze 2014-01-20 20:04:39 UTC
Created attachment 92485 [details]
This is what the filter should look like after FILEOPEN
Comment 2 m_a_riosv 2014-01-21 22:40:46 UTC
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.
Comment 3 Sebastian Goetze 2014-01-22 15:19:39 UTC
@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...
Comment 4 raal 2014-10-17 15:34:15 UTC
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
Comment 5 Xisco Faulí 2014-10-20 09:25:39 UTC
Remove 'bisected' from Keyword as the commit that caused this regression hasn't been identified yet.
Comment 6 raal 2015-05-22 07:54:27 UTC
*** Bug 91412 has been marked as a duplicate of this bug. ***
Comment 7 Robinson Tryon (qubit) 2015-12-13 11:09:35 UTC Comment hidden (obsolete)
Comment 8 bugzilla 2016-04-02 10:01:47 UTC
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.
Comment 9 rajat 2016-11-21 15:38:30 UTC
This is bug is still present in 5.2.0.4
Filter is not retained after save-close-open
Comment 11 QA Administrators 2018-09-20 02:51:11 UTC Comment hidden (obsolete)
Comment 12 marc 2018-11-20 10:44:49 UTC Comment hidden (obsolete)
Comment 13 marc 2019-11-11 08:11:29 UTC Comment hidden (obsolete)
Comment 14 marc 2020-06-14 09:47:48 UTC Comment hidden (obsolete)
Comment 15 Sebastian Goetze 2020-12-03 14:52:59 UTC Comment hidden (obsolete)
Comment 16 Sebastian Goetze 2020-12-28 21:14:22 UTC Comment hidden (obsolete)
Comment 17 Sebastian Goetze 2021-02-04 11:32:44 UTC Comment hidden (obsolete)
Comment 18 marc 2021-09-30 22:25:48 UTC Comment hidden (obsolete)
Comment 19 marc 2022-03-29 11:14:22 UTC
still there in 7.3.1_rc3 
:-(
Comment 20 Mike Kaganski 2022-09-03 14:31:15 UTC
Looks like regression from commit 5897d4a60f766ca0cd751281e7c32af3df677303.
Comment 21 Commit Notification 2022-09-05 09:43:08 UTC
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.
Comment 22 Commit Notification 2022-09-05 19:54:57 UTC
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.
Comment 23 Sebastian Goetze 2022-09-30 15:07:31 UTC
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
Comment 24 Buovjaga 2022-10-09 18:34:03 UTC
Sounds like we can change status to fixed
Comment 25 marc 2022-10-13 22:16:46 UTC
Fixed in 7.4.2.3 (linux mint 21)

Thanks a lot