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.
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.
Created attachment 116289 [details] sample file
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.
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.
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.
(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
hm, i tried else one. result changed all the same even if formula =aaa+2*bbb
https://gerrit.libreoffice.org/55789
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.
backport in to 6.1 and 6.0?
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.
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.