Bug 74177

Summary: EDITING TABLE: using comments on cells is incompatible with formulas
Product: LibreOffice Reporter: Mike Kaganski <mikekaganski>
Component: WriterAssignee: Not Assigned <libreoffice-bugs>
Status: NEW --- QA Contact:
Severity: critical    
Priority: high CC: gautier.sophie, luuk34
Version: Inherited From OOo   
Hardware: All   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: bugdoc

Description Mike Kaganski 2014-01-29 12:38:36 UTC
Created attachment 92992 [details]
bugdoc

Inserting a comment to a table cell with a manually written number makes that number inaccessible to formulas that refer to that cell.
Inserting a comment to a cell with a formula freezes the displayed value of that cell, while the underlying formula is still evaluated properly, which can be observed in other formulas that refer to that cell.

Steps to reproduce:
1. Create a new text document, add a table 3x3.
2. In the first column (A), insert values 1, 2, 3.
3. In columns B and C, insert formulas that refer to the neighbour left cell. E.g., insert into <B1> a formula like this: =(<A1>+1)*2, and copy the cell to other cells of the two columns.

Now the table has these numbers:
1  4  10
2  6  14
3  8  18

4. Put caret into <A2> cell, press Ctrl+Alt+C to insert a comment; put some text to the comment.
5. Tools->Update->Update All
6. Put caret into <B3> cell, press Ctrl+Alt+C to insert a comment; put some text to the comment.
7. Go to cell <A3> and change its contents to 4.

Expected results:
After step 5, the table must still look like this:
1  4  10
2  6  14
3  8  18
After step 7, the table must become like this:
1  4  10
2  6  14
4  10  22

Actual results:
After step 5, the table becomes this:
1  4  10
2  2  6
3  8  18
After step 7, the table becomes this:
1  4  10
2  2  6
4  8  22

The second row shows that the cell A2 is no longer considered to hold a number (although the number is indeed displayed in the cell). The result of the formula in <B2> is as if <A2> hold 0.
The third row shows that the <B3> shows incorrect outdated value (that was actual at the time the comment was inserted), but the formula in that cell is still active, and gives correct (invisible) result that is used by <C3>.

The problem persists after updating, and after save/close/reopen.

The impact is that it is impossible to use comments on tables. Using them may give unnoticed wrong results that are tricky to track down, especially in complex big tables, where one may not notice that come cells change (or don't change) as they should.
While it could be considered an enhancement request (on grounds that this will just broaden the comments feature to support new usage scenario), I think that this is actually a rather severe bug:
Using comments on individual cells seems natural, especially in complex tables, where those comments could help to clarify/remind what is contained/counted.
Even if using comments on tables with formulas is not permitted at the moment, this should be noted in the documentation, as well as measures must be taken to prevent undesired behaviour, e.g. by disabling comments in tables, or displaying proper notifications when either a comment is inserted into cell with formula/referenced by formula, or a formula is created that references a commented cell.
For now, the behaviour is inconsistent and is not what one would expect, causes difficult-to-notice (but probably severe) errors in data in professional documents.

This problem is inherited from OOo, is already reproducible with OOo 3.3.0.
Reproducible with 4.1.4.2 under Ubuntu 13.10 x64, and 4.2.0.3 under Win7x64.

Attached is a test document with a table before inserting comments, and another with comments inserted and <A3> modified, to reproduce the problem.
Comment 1 sophie 2014-01-29 13:13:48 UTC
I can confirm using your document using Version: 4.2.0.4
Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71 on Ubuntu 13.10 - Set as New - Sophie
Comment 2 sergio.callegari 2014-05-23 13:07:21 UTC
Verified on 4.2.4.2

Rised priority to high, since tables with formulas can be used for *contracts* and having LibO getting numbers wrong in a contract can be quite serious.
It's completely inacceptable that a program that is supposed to do math provides incorrect results. Rised severity to critical for the same reason.

Note that in the short term it may not be necessary to fully fix the bug, but at least to assure that an *error is returned* if there are comments that make computations impossible.  Here, the issue is that values are returned that may seem realistic, but that are not the correct ones.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.