Bug 37987 - FORMATTING EDITING Calc Conditional Formatting - Incorrect cell references after line or column insertions
Summary: FORMATTING EDITING Calc Conditional Formatting - Incorrect cell references af...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.3.2 release
Hardware: x86 (IA32) All
: low normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-06 05:46 UTC by Christopher M. Penalver
Modified: 2013-05-15 11:10 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Conditional formatting example.ods (12.36 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-06-06 05:46 UTC, Christopher M. Penalver
Details
conditional formatting problem with delete row/column as well (7.37 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-11-07 02:42 UTC, Winfried Donkers
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher M. Penalver 2011-06-06 05:46:49 UTC
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.
Comment 1 Winfried Donkers 2011-10-10 02:58:06 UTC
I confirm behaviour witj LO 3.4.3 (release) and Windows O/S.
Comment 2 Christopher M. Penalver 2011-10-10 09:04:08 UTC
Dnk1287, please do not toggle the version. For more details please see http://wiki.documentfoundation.org/BugReport_Details#Version
Comment 3 Winfried Donkers 2011-11-07 02:42:48 UTC
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))
Comment 4 Björn Michaelsen 2011-12-23 12:01:26 UTC
[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
Comment 5 Winfried Donkers 2011-12-24 01:02:59 UTC
The bug still persists on master (3.6.0alpha+, sources from 23 dec. 2011, openSUSE 12.1)
Comment 6 Winfried Donkers 2012-01-02 23:00:36 UTC
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.
Comment 7 Eike Rathke 2012-01-04 10:24:03 UTC
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.
Comment 8 Winfried Donkers 2012-01-04 22:49:37 UTC
(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).
Comment 9 m.a.riosv 2012-02-09 18:11:21 UTC
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.
Comment 10 libreoffice-bugs 2012-06-15 12:56:02 UTC
(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.
Comment 11 m.a.riosv 2012-08-01 00:24:52 UTC
(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.
Comment 12 Markus Mohrhard 2013-03-12 23:24:08 UTC
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.
Comment 13 Christopher M. Penalver 2013-05-15 11:10:30 UTC
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