Bug 61078 - EDITING and TABLE: Variables in TABLE not resolved
Summary: EDITING and TABLE: Variables in TABLE not resolved
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.6.0.0.alpha1
Hardware: Other All
: high normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2013-02-18 18:32 UTC by ecm4u
Modified: 2013-05-04 02:11 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Testcase (9.75 KB, application/vnd.oasis.opendocument.text)
2013-02-18 18:32 UTC, ecm4u
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ecm4u 2013-02-18 18:32:08 UTC
Created attachment 75067 [details]
Testcase

using variables in formula in tables cells returns 0.

how to reproduce: create new writer document.
insert a variable:
Insert > Reference > Variables > Set Variable > Name:test, Value:111
insert a table (e.g. 2 rows, 2 columns)
select a cell and press F2.
insert fomula: "=test"
press return
result: value in cell is "0"
expected behavior:"111"
Comment 1 Mike Kaganski 2013-03-09 23:50:55 UTC
It is still reproducible in 4.0.1 under Windows 8; in 3.6.x it works OK, thus adding keyword "regression".
Comment 2 Joel Madero 2013-03-21 20:38:02 UTC
Per comment #2, verified. 

Marking as

New (confirmed)
Normal - can prevent high quality work
High - regression from 3.6, bumped it up from "medium"

Whiteboard - bibisectrequest

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 
LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link:
https://wiki.documentfoundation.org/QA/BugTriage

There are also other ways to get involved including with marketing, UX, documentation, and of course developing -  http://www.libreoffice.org/get-help/mailing-lists/. 

Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
Comment 3 Joel Madero 2013-05-02 17:51:26 UTC
So I've tried bibisecting and all the way back to 3.6 alpha 1 I see the same behavior so as far as I can tell this is not a regression.

The behavior is that if you just open the file it does indeed say 0, but if you click on it then click off it changes to 111 (which is correct).

Removing regression as well as bibisectrequest as bibisectrequest is useless and I can't confirm that it ever worked any other way in 3.6.x.x.


If I am mistaken and it's some other behavior, please explain what I am missing and tell me what version exactly I can see the right behavior (and what the right behavior that you are witnessing is)
Comment 4 Mike Kaganski 2013-05-03 23:54:35 UTC
In reply to Comment 3:

What you describe is the correct desired behavior. The problem is clearly depicted in Description (with steps to recreate, without using the attached testcase): the 0 stays, and you cannot use variables in tables.

Just tested with 4.0.1.2: problem exists.
Then updated to 4.0.2.2: problem is GONE! Great! Looks like it was fixed in between. Thanks to developers, and thank you Joel for your work and attention to users' problems!

Thus, marking accordingly.
Comment 5 Joel Madero 2013-05-04 02:11:50 UTC
No problema :)

As for version - it's the oldest version that we can see the issue - I saw it in earliest bibisect which is 3.6 alpha :)

and for FIXED, we only mark something as FIXED if we know the commit (patch) that fixed it. We mark a bug as WORKSFORME if it just got fixed without knowing how, when or by whom :)

Thanks for the positive feedback!