Created attachment 47597 [details] Conditional formatting example.ods Downstream bug may be found at: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/235602 OOo bug may be found at: http://openoffice.org/bugzilla/show_bug.cgi?id=4155 1) lsb_release -rd Description: Ubuntu 11.04 Release: 11.04 2) apt-cache policy libreoffice-calc libreoffice-calc: Installed: 1:3.3.2-1ubuntu5 Candidate: 1:3.3.2-1ubuntu5 Version table: *** 1:3.3.2-1ubuntu5 0 500 http://us.archive.ubuntu.com/ubuntu/ natty-updates/main i386 Packages 100 /var/lib/dpkg/status 1:3.3.2-1ubuntu4 0 500 http://us.archive.ubuntu.com/ubuntu/ natty/main i386 Packages 3) What is expected to happen with LibreOffice Calc via the Terminal: cd ~/Desktop && wget https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/235602/+attachment/321005/+files/Conditional%20formatting%20example.ods && localc -nologo 'Conditional formatting example.ods' place the cursor in row 12 -> Insert -> Row and all the rows move down, and the highlighting does not change. 4) What happens instead is B13 and D13 lose their highlighting.
I confirm behaviour witj LO 3.4.3 (release) and Windows O/S.
Dnk1287, please do not toggle the version. For more details please see http://wiki.documentfoundation.org/BugReport_Details#Version
Created attachment 53237 [details] conditional formatting problem with delete row/column as well A similar problem occurs with row/column removal as well; see attachment. When you remove column A or column C, either the condition for E2 or E3 becomes incorrect. (Windows with version 3.4.3 and Linux with version 3.5.0))
[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
The bug still persists on master (3.6.0alpha+, sources from 23 dec. 2011, openSUSE 12.1)
The bug also occurs when dragging selected rows/columns and using the shortcut key Alt to move them. version 3.4.4 on Windows XP, as well as master on openSUSE 12.1 The behaviour seems related to bug 42261 and bug 44383.
This is not related to bug 42261 or bug 44383. The problem originates from how conditional formats are implemented, one conditional can be applied to multiple cells, when moved around they behave like named ranges and relative references are not updated but applied to the then current position instead. There's no easy fix for this; splitting conditionals and creating duplicates to be updated could be a possibility, somewhat similar to how internal shared formulas are treated.
(In reply to comment #7) > This is not related to bug 42261 or bug 44383. > > The problem originates from how conditional formats are implemented, one > conditional can be applied to multiple cells, when moved around they behave > like named ranges and relative references are not updated but applied to the > then current position instead. > > There's no easy fix for this; splitting conditionals and creating duplicates to > be updated could be a possibility, somewhat similar to how internal shared > formulas are treated. I understand the why now, but I fear that the average user will not understand this. In his/her view the conditional formatting of cell(s) is damaged when inserting row(s)/column(s).
I don't know if it's a similar problem, but in the Menu/Data/Consolidation the ranges are not update even the absolute references. May be an advice line about the limitation in the options where this happens could help to dealt with.
(In reply to comment #8) > I understand the why now, but I fear that the average user will not understand > this. In his/her view the conditional formatting of cell(s) is damaged when > inserting row(s)/column(s). I must be the average user you mention, because I'm afraid that the current behaviour definitely appears to be buggy to me. To me, cell references used within conditional formatting should mimic the behaviour of cell references used in cell formulas. That is, if a formula (or conditional formatting) refers to another cell and that other cell is moved then the formula (or conditional formatting) should be updated to reflect that. As far as I know cell formulas *always* behave this way. Also, just so not to confuse a separate issue, the use of A1 vs. $A$1 vs. $Sheet1.$A$1 should make no difference to what I said above. So I don't really understand why when a precedent cell is moved that the address used in a conditional format of the dependent cell is not updated just like it is for cell formulas. The behaviour is also not consistent depending on the addressing mode used. Please try again the original test case ( https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/235602/+attachment/321005/+files/Conditional%20formatting%20example.ods ) Insert a row above row 11, and you should see cells B12 - E12 (now B13 - E13) retain their green formatting. OK so far. Now starting with the original test case again, make the following modification: In cells B12 to E12, change the conditional formatting to _not_ use sheet names. That is remove the prefix $Tabell1. from the conditional formatting test in each. In fact so it looks just like the format documented in row 8. Insert a row above row 11, and C12 & E12 (now C13 & E13) lose their green formatting. So, the $Tabell1. prefix is critical to the behaviour. I think it should have no impact, just as it would not matter when used in a cell formula. I hope that all makes sense. I'm using: LibreOffice 3.5.4.2 Build ID: 165a79a-7059095-e13bb37-fef39a4-9503d18 Windows XP. Thanks for making LO a great product.
(In reply to comment #10) IMHO you are right, the behavior of references must be always the same, in cells, functions, names ranges, data ranges, moving or inserting or deleting cells/columns/rows, in any place in the application where references are used. Maybe not easy to implement but a target for sooner than later. Once gotten, less things to think about for devs.
I suppose this bug can be closed. There is one issue left about wrong updates in master/4.0 but except for that the new range based design handles reference updates in conditional formats quite well. Please test in 4.0.2 and report if you think it is fixed.
Problem noted in Description https://bugs.freedesktop.org/show_bug.cgi?id=37987#c0 not reproducible in: Version: 4.1.0.0.alpha1+ Build ID: fe93ea66cc3d75209ec535f34c260fd7414b066 TinderBox: Win-x86@6, Branch:master, Time: 2013-05-12_03:15:23 Microsoft Windows Vista Business x86 6.0.6002 Service Pack 2 Build 6002