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.