When using conditional formatting on cells in pivot table, calling refresh (via right mouse button contectmenu-refresh or via menu-data-pivot table-refresh) to update the pivot table (e.g. after changes in the data tables) causes the conditional formatting to disappear.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
bug still present on master (3.6.0alpha+, openSUSE 12.1)
Ok, now that I am registered with Bugzilla, I am confirming that this bug persists in 3.5. Hoping it gets fixed soon.
I think is not a bug, Pivot tables always overwrite all the destination area, values and formats. Maybe can be set as enhancement.
** 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 on a currently supported version of LibreOffice (4.3.5 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) Thank you for your help! -- The LibreOffice QA Team
Problem still persists in version 4.3.5.2 My current master is broken, so cant test there. WRT comment #4 I think that refreshing pivot tables should just overwrite the values, not the formatting.
Using current version 4.4.0.3 and working with Calc. Pivot tables are formatted using one set of format titles in the Styles library If using several pivots against the same set of data, such as to create an order, invoice, bill of lading, summary, etc., it would be useful to allow each table to use its own formatting. Suggestion: When editing a pivot, have the option to retain formatting that has been applied or overwrite formatting on refresh. (As is permitted in Excel). This is my first post, so please forgive if submitted incorrectly.
** 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 on a currently supported version of LibreOffice (5.0.5 or 5.1.0) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-02-21
Problem still there in version 5.0.4 (Windows 7).
** 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 on a currently supported version of LibreOffice (5.2.5 or 5.3.0 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170306
Problem still there in version 5.2.5 (Windows 7).
** 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
Problem still there in version 6.1.5.2 (Windows 10).
I can confirm this bug for 6.3.2.2 x64 on Windows 10. Also sorting gets lost on refresh.
Same here 6.3.2.2
Reproduced in: Version: 7.3.0.0.beta1 / LibreOffice Community Build ID: 436f14c25ec1847646b953cf13d0db4f7ca3be57 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Generalising the summary to all formatting, as many bugs refer to the same issue and should be marked as duplicates of this one.
affects all OSs
*** Bug 126557 has been marked as a duplicate of this bug. ***
*** Bug 104174 has been marked as a duplicate of this bug. ***
Issue is inherited from OOo, as mentioned in bug 126557
*** Bug 133520 has been marked as a duplicate of this bug. ***
Possibly related to bug 122472
It has been marked that this bug is duplicate of my bug report 126557 However, 1/ I clearly state in bug report 126557, that there is no undo, aka a bug. 2/ I give a presumable cause, aka the refresh calls some kind of new constructor and not as it must an update/refresh one, prevailing the undo action! I consider no undo as severe.
*** Bug 145098 has been marked as a duplicate of this bug. ***
NOT REPRODUCED When using conditional formatting on cells in pivot table, calling refresh (via right mouse button contectmenu-refresh or via menu-data-pivot table-refresh) to update the pivot table (e.g. after changes in the data tables) causes the conditional formatting to disappear. bug not produced during by clicking the refresh button. ENVIRONMENT: libre office 7.4.0.0 Distributor ID: Linuxmint Description: Linux Mint 20.3 Release: 20.3 Codename: una
Duplicate bug 104174 provided TESTING.ods with attachment 129016 [details]. Using that, I can repro in 7.5+, including the inability to undo. Can someone provide a reason why formatting WOULD be replaced? As Gordon noted in comment 7, it is applying the predefined "Pivot Table" styles. But in what situation would be it be necessary to reapply? Oh, I see. Pivot tables can grown or shrink on a refresh, covering a different range of cells. So as Gordon astutely pointed out, the only proper "solution" is to give the user a choice.
One could argue that the mere presence of direct formatting in the pivot table should be enough to prevent a reformatting - at least as long as the table doesn't change in size. (I would say that automatic formatting should be guaranteed when the size changes - removed completely when shrunk, and appropriately applied when increased.)
The recalc is initiated by an event call to ScDBFunc::RecalcPivotTable() which calls RefreshPivotTables (with bApi = false). //Reload the referenced pivot cache, and refresh all pivot tables // that reference the cache. RefreshPivotTables has a note // This action is intentionally not undoable since it modifies cache. ScDBDocFunc::UpdatePivotTable compares the old and new size, verifying that it won't overwrite non-pivot-table content. It calls rDPObj.Output(aNewOut.aStart) which right away calls DeleteArea with InsertDeleteFlags::ALL. I suppose we want to keep all except InsertDeleteFlags::CONTENTS and FORMULA? Proposed fix at gerrit.libreoffice.org/c/core/+/141600
(In reply to Sven Neuz (SERPENTEQ) from comment #14) > Also sorting gets lost on refresh. Sorting isn't a property, is it? Is there any other place where a sort is automatically triggered after the content changes?
*** Bug 157248 has been marked as a duplicate of this bug. ***
Still reproduced in: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8705cfecd5a10f817d3a2a02041d85e77282aa30 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded Despite recent pivot table formatting-related commit by Quikee: https://gerrit.libreoffice.org/q/owner:quikee@gmail.com+status:merged+mergedbefore:2024-05-01+mergedafter:2024-03-31+pivot Quikee, after looking into PT formatting in depth, any comment on this particular issue?