Bug 91801

Summary:	Calculations in tables with variables would cut off part of the calculation upon print
Product:	LibreOffice	Reporter:	mchan223
Component:	Writer	Assignee:	Mike Kaganski <mikekaganski>
Status:	RESOLVED FIXED
Severity:	major	CC:	79045_79045, xiscofauli
Priority:	medium	Keywords:	needsDevAdvice
Version:	4.4.3.2 release
Hardware:	x86-64 (AMD64)
OS:	Windows (All)
See Also:	https://bugs.documentfoundation.org/show_bug.cgi?id=61228
Whiteboard:	target:6.2.0 target:6.1.0.1
Crash report or crash signature:		Regression By:
Bug Depends on:
Bug Blocks:	108253
Attachments:	sample file

Description mchan223 2015-06-01 19:10:40 UTC

Steps:
1. Set up some variables.
2. Create a table and insert a calculation involving at least 1 variable.
3. See the calculation appear correctly.
4. Attempt to print or convert to PDF.

Expected:
5. Document prints with the correct result.

Actual:
5. Document prints another result, as though part of the equation were cut off (0 for 1 variable, only the first variable for 2).
The change can be seen on the display if attempting to print, but when converting to PDF the change is not shown until you open the PDF.


Sample file attached. This also happens if I open the file and then immediately click inside the cell.

Set to "HIGH" because this cost us just under $200 due to a miscalculation in a statement and has the potential to do much worse when bigger numbers are involved.

Comment 1 Gordo 2015-06-04 18:07:16 UTC

Could you please attach the sample file and the pdf.

Set to NEEDINFO.  Please change back to UNCONFIRMED once the necessary information has been provided.

Comment 2 mchan223 2015-06-04 18:16:10 UTC

Created attachment 116289 [details]
sample file

Comment 3 Gordo 2015-06-04 18:44:57 UTC

You need to insert the variables into the document so that they can be referenced.  If you don't want them to be seen when printing then set them to invisible before you insert them.

Changed to RESOLVED WORKSFORME.

Comment 4 mchan223 2015-06-04 18:50:20 UTC

That makes no sense - why would they have to be inserted if the values are already stored? It's a completely arbitrary and unintuitive extra step.

Changing to REOPENED.

Comment 5 Gordo 2015-06-05 11:28:34 UTC

Is traversing a menu that says Insert -> Fields not already an indicator?  The whole point of fields is to use them in the document.  The help on the Fields -> Variables dialogue says that a User Field:  "Inserts a custom global variable. You can use the User Field to define a variable for a condition statement. When you change a User Field, all instances of the variable in the document are updated."

Anyway, I have thought about it some more.  I think what is happening in the table is that because the field hasn't been inserted it thinks that "= <field name>" is an insert field action so it is truncating the rest of the formula.  If the formula does not start with the field name, e.g. = 1 +  <field name>, then it will display correctly when converting to pdf.  As a workaround you could use "= 0 +" at the beginning of the formula.

Comment 6 Roman Kuznetsov 2018-06-13 19:23:02 UTC

(In reply to mchan223 from comment #4)
> That makes no sense - why would they have to be inserted if the values are
> already stored? It's a completely arbitrary and unintuitive extra step.
> 
> Changing to REOPENED.

i agree with mchan223 , there are variables and we can use it.
result of calculation shouldn't change to incorrect! It is a bug.

three cents from me:

1. if formula in table change to aaa+2*bbb, then result doesn't change
2. may be sign [*] after of name of variable [bbb] makes from it name of another variable [bbb*2], that doesn't set in the document? 
3. [*] may be a wildcard in this case?

finally, in 6.1 beta 1 this bug still repro

Status -> NEW

Comment 7 Roman Kuznetsov 2018-06-13 19:27:57 UTC

hm, i tried else one. result changed all the same even if formula =aaa+2*bbb

Comment 8 Mike Kaganski 2018-06-14 10:32:02 UTC

https://gerrit.libreoffice.org/55789

Comment 9 Commit Notification 2018-06-15 01:16:21 UTC

Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=82fc1fdebc622507d4220fefa72b9b4bda0f55d8

tdf#91801: also restore command (formula) string on validating value

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Comment 10 Roman Kuznetsov 2018-06-15 07:53:50 UTC

backport in to 6.1 and 6.0?

Comment 11 Commit Notification 2018-06-15 08:55:08 UTC

Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=53ed11accf52481ae0669b5b1676d73b05f38cf4&h=libreoffice-6-1

tdf#91801: also restore command (formula) string on validating value

It will be available in 6.1.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Comment 12 Mike Kaganski 2018-06-15 08:56:12 UTC

Backporting to 6-0 should be easy (small changes to the placement of the unit test, which disallows automated backporting); but I don't have spare cycles ATM for that, so whoever feels inclined to do that, please do.