[upstream] [hardy] Calc Conditional Formatting - Incorrect cell references after line or column insertions

[Bowmore]

Binary package hint: openoffice.org-calc

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.

Original Reporter Comments: Ubuntu 8.04 LTS OpenOffice.org Calc Version: 1:2.4.0-3ubuntu6

[Bowmore (bowmore)]

Another way of expressing this issue is that references for conditional formatting and references explicitly given in corresponding cells shall be treated (modified) in the same way when adding rows and/or columns to the spreadsheet. Currently, this is not always the case.

[Chris Cheney (ccheney)]

Do you still have this problem with openoffice.org 1:2.4.1-1ubuntu2 in Ubuntu 8.04? I can't reproduce this issue with the current version.

[Bowmore (bowmore)]

Yes, I still have this problem.

I think this bug has been there for quite a while but not detected probably because this nice little feature is not frequently used. Myself I detected it when porting Excel documents to Calc.

I attach an ods file as an example.

[Chris Cheney (ccheney)]

How do you view the conditional formatting rules that are applied, I couldn't find them in the Format Cells menu.

Thanks,

Chris Cheney

[Chris Cheney (ccheney)]

Oh nevermind I found it is hidden away under Format menu on the main menubar.

[Chris Cheney (ccheney)]

I now understand why I didn't see the bug I didn't look in the right location before, the example file was very helpful and I found an upstream bug report relating to the issue which I have linked.

Thanks,

Chris

[Bowmore (bowmore)]

Thanks Chris for taking your time.

The issue 4155 you linked to was raised in 2002 (six year ago) but still not solved! They refer to the modelling of the feature and claim it is an enhancement rather than a bug. But this is not the case, it's a pure bug, probably in the model itself! As I wrote the absolute and relative addressing for conditional formatting and for explicit formulas given in cells shall act the same way when e.g. adding/deleting rows and columns.

In my case it is a severe bug as I use this feature frequently with hundreds of them per document so updating each and every one to absolute address, e.g. $B$2, is not realistic. Thus I have to keep to MS and Excel for those documents until they fix this issue.

Hopefully this will happen soon but the story so far does not give much hope!

Anyway, thanks again.

[pboosman (pieter-boosman)]

Possibly a bit more detailed information for the bug-solver:

I use a column, let's say J, with conditional formatting based on the values in column D.
When I insert a "new" column left from D (or more than one column), the references are updated.
When I insert a column between D and J, the references are NOT updated.

This should help to isolate the problem.
Good luck developers.

[Bowmore (bowmore)]

pboosman, what type of conditional formatting reference did you use in your example?

If you by "updated" mean "updated correctly" that behaviour only applies as far as I can see to relative addressing of columns, i.e columns not prefixed by $. For absolute addressed columns I get the opposite result.

[penalvch (penalvch)]

Bowmore, this issue is unreproducible in 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'

Inserted a row above row 12 and inserted a column to the left of column 14, the conditionally formatted cell references were not changed. Does this work for you?

lsb_release -rd
Description: Ubuntu 11.04
Release: 11.04

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

[Bowmore (bowmore)]

No, it still does not work correctly neither for OO nor LO.

Cell references shall act the same way independent of whether they are specified explicilty in the cell itself or by using conditional formatting.

A correct result is that all four cells on row 12 remain green when moved to row 13 after you insert an empty row inbetween row 11 and 12.

The references explicitly given in a cell works and you can check the discrepancy further by replacing the absolute values (1) in cells B12-E12 by a reference to its cells above, i.e
- contents of cell B12 changed from value 1 to the reference =B11
- contents of cell C12 changed from value 1 to the reference =C$11
- contents of cell D12 changed from value 1 to the reference =$D11
- contents of cell E12 changed from value 1 to the reference =$E$11

thus the same references as stated for conditions formatting.

Now if you insert an empty row inbetween row 11 and 12 you will see that the cells now on row 13 all still equals 1 BUT only two of those cells remain green. If correct all those four cells also shall remain green.

Running LibreOffice 3.3.2

[penalvch (penalvch)]

Created attachment 47597
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.

[Björn Michaelsen (bjoern-michaelsen)]

[This is an automated message.]
There are no new official OpenOffice.org releases in Ubuntu packaging anymore => Won't Fix

If the problem persists, please mark this bug as "also affects project Libreoffice" or "also affects distribution Libreoffice (Ubuntu)" if that has not happened already.

Please leave references to upstream OpenOffice.org bugs in place to allow cross pollination.

[E-osc (e-osc)]

I confirm behaviour witj LO 3.4.3 (release) and Windows O/S.

[penalvch (penalvch)]

Dnk1287, please do not toggle the version. For more details please see http://wiki.documentfoundation.org/BugReport_Details#Version

[E-osc (e-osc)]

Created attachment 53237
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))

[Björn Michaelsen (bjoern-michaelsen)]

[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

[E-osc (e-osc)]

The bug still persists on master (3.6.0alpha+, sources from 23 dec. 2011, openSUSE 12.1)

[E-osc (e-osc)]

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.

[Eike Rathke (erack)]

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.

[E-osc (e-osc)]

(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).

[Mariosv (mariosv)]

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.

[Libreoffice-bugs-i (libreoffice-bugs-i)]

(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.

[Mariosv (mariosv)]

(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.

[Markus Mohrhard (moggi)]

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.

[penalvch (penalvch)]

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

[Björn Michaelsen (bjoern-michaelsen)]

closing as per comment 25 from upstream