Description: The behaviour of insert-column on an area with conditional formatting depends on conditional formatting present in other parts of the sheet. Sometimes it updates correctly, sometimes it does not. localc 6.4.4.2 as supplied in Linux Mint 20 (Ulyana) Steps to Reproduce: Load to-be-attached cf1.ods. The colours in the right-hand block come from conditional formatting based on the block of values to the left using relative cell references. Insert a new column before column C and notice that the coloured block moves to the right correctly. This works fine. Now load cf2.ods. It's the same file, except that c7:h9 has been copied to a14:f16. Insert a new column before column C and notice that this time the conditional formatting breaks for h7:i9. This is because the conditional formatting still refers to c7:d9 instead of d7:e9 Before the column insert, the original and the copy have the same conditional formatting. They also do afterwards (ie., one line in the manage-conditional- formatting dialog) but they need to be different (two lines) because the relative references need to be updated differently. Actual Results: With cf2.ods, the conditional formatting ends up referring to c7:d9. As a consequence, h7:h9 is displayed wrong. Expected Results: With cf2.ods, the conditional formatting should end up referring to d7:e9. h7:i9 should look like g7:h9 did before the insert. Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: SpreadsheetDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes
Created attachment 162948 [details] cf1.ods Insert before column C works fine with this file.
Created attachment 162949 [details] cf2.ods Insert column before column C fails with this file.
Reproduced in Version: 7.1.0.0.alpha0+ Build ID: d851a02df57ab378ed0cc6d9362516de09c3279c CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=a93bb27aa46c84410c8848a6118d5d63d47be92c author Kohei Yoshida <kohei.yoshida@collabora.com> 2014-05-13 12:35:24 -0400 committer Kohei Yoshida <kohei.yoshida@collabora.com> 2014-05-13 12:37:14 -0400 commit a93bb27aa46c84410c8848a6118d5d63d47be92c (patch) tree f73842e0d78806d9b62980358485b363eb5a3a10 parent 49bf3a1f5f38cdf259101b15a19d546b32151463 (diff) fdo#78402: Adjust references of validity entries as appropriate. Bisected with: bibisect-43max Adding Cc: to Kohei Yoshida
@Dennis, @Luboš, I thought you might be interested in this issue
repro 7.3+
repro 7.6+
Bah - I should have bibisected myself. This bibisect result is not accurate. Sure, the cells H7:I9 look fine before Kohei's commit, but the same problem described is seen on cells F14:G16 (except in reverse). That problem was already seen in OOo 3.3. This cannot be a bug AFAICS. There is only one formula that describes the formatting for all the cells. The formula basically breaks down to "look at the cell 4 columns ahead of you and see whether it is a 1 or a 2." After the column insertion, the top block needs to look 4 ahead, and the bottom block needs to look 5 ahead. One rule cannot say that. Now, granted, OP says that LO should be smart enough to replicate the rule so that each broken situation is fixed, and non-broken situations are unaffected. That seems a little far-fetched to me. Perhaps a calc genius could do that. But I certainly wouldn't expect a program to be able to be smart enough to know exactly what to do in this circumstance. And LO certainly didn't do it properly before this. Removing "regression" and lowering priority.
Dear mwelinder, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug