Created attachment 106623 [details]
Demonstration of issue
If I change the condition on a conditional text field, this causes a hidden section to unhide.
1. Insert variable varA with value "is" (without the quotes)
-- a. Insert > Fields > Other > Variables > Set Variable
-- b. Name: varA
-- c. Value: is
-- d. Click Insert
2. Press enter
3. Insert variable varB with value "is" (without the quotes)
-- same as step 1 with name varB
4. Press enter
5. Insert a conditional field based on varA
-- a. Insert > Fields > Other > Functions > Conditional Text
-- b. Condition: varA EQ "is" (with the quotes)
-- c. Then: Ais
-- d. Else: AisNot
-- e. Click OK
6. Press enter
7. Insert two section based on varB
-- a. Type "Hide this section if varB is" (without the quotes)
-- b. Press enter
-- c. Type "Hide this section if varB is not" (ditto)
-- d. Select the first of the two lines
-- e. Insert > Section
-- f. Check Hide
-- g. Condition: varB EQ "is"
-- h. Select the second of the two lines
-- i. Insert > Section
-- j. Check Hide
-- k. Condition: varB NEQ "is"
Actual result: "Hide this section if varB is" shows, "Hide this section if varB is not" is hidden
Expected result: "Hide this section if varB is" is hidden, "Hide this section if varB is not" shows
Attachment is at this point.
Actually 22.214.171.124 but that's not offered in the dropdown at time of filing.
Hardware is Intel Core 2 Duo
*** Bug 84148 has been marked as a duplicate of this bug. ***
I can reproduce this behaviour on OSX 10.9.4
LO Version: 126.96.36.199.alpha0+
Build ID: e9645402b1e5aaf399aed68fe961fe6ebdb2df1e
Doesn't work in LO Version 188.8.131.52 (Build ID: e183d5b) either.
Same behaviour also present in OOo 321 (320m18) so this behaviour is inherited from OOo
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present on a currently supported version of LibreOffice
(5.1.6 or 5.2.3 https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the version of LibreOffice and
your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave
a short comment that includes your version of LibreOffice and Operating System
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to "inherited from OOo";
4b. If the bug was not present in 3.3 - add "regression" to keyword
Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
This works as intended, and is not a bug; but please see at the end of the comment.
Inserting a "Set variable" field *for the first time*, you *define* a variable in the document; and also *define its type*, which can be *numeric* or *textual*. After the definition, you can't change the type (until you remove the variable from document using "cross" button in "Set variable" insertion dialog).
By default, all variables are created of numeric type.
Setting a variable's type is done by assigning it "Text" *format* when creating it.
When a variable is created numeric, i.e. not assigned "Text" format when created, its value is treated as a formula, and its result is converted to number. E.g., putting "is" with quotes would make the variable equal to result of conversion of text "is" to a number, which is 0. Putting "123a456" in quotes would result in number 123, because conversion to number stops at non-numeric character "a". `1+2` (without quotes) gives 3. Putting `pi` (without quotes) into the value of the numeric variable produces result of 3.14..., using one of predefined values  (note that value names are case-insensitive). When you have created a numeric variable varA with value 3, creating numeric varB with formula `varA + 1` will give 4.
For a numeric variable, there is a specific situation when you put an undefined name into its value box. E.g., creating numeric varA with value `is` without quotes, when no variable `is` was defined, produces varA variable with *empty* value, which e.g. also produces empty results of formulas like `varA + 1`.
When a variable is defined textual (by setting its format to Text upon its creation), anything you write into the value box is treated as plain string (except when you put an existing variable name); e.g., putting `is` without quotes into the value box (assuming there's no variable `is` predefined) will produce string "is", which might be tested using condition `var EQ "is"` ; putting "is" *with* quotes into the value box will produce 4-character string *containing the quotes*, so the condition `var EQ "is"` would fail this time; `1+2` would produce string "1+2". But when you have a variable txtA containing "AAA", and you create another textual txtB with value `txtA`, txtB will contain AAA.
Note again that trying to change existing variable type after creation will not work, neither in "Set variable field", nor in "Show variable", "Input field", or others.
So your steps in comment 0 lack a step between 1.b and 1.c, which would be
1.b.1. Format: Text
With that, your document will work => NOTABUG.
Now I agree that there a problem with the Set Variable fields, worth a separate issue:
The aspects of *creation* of a variable; *variables having a type*; and other variable manipulations (e.g., that variables don't get deleted when the last field setting/using it is removed; or inability to change type; or empty result when using undefined names in numeric variables; or using predefined variable names in textual variables) are unclear, not intuitive, and not well documented and represented in UI. There's tdf#111888 regarding one of aspects of variable manipulation, but unrelated to this issue (which is about variable types).
Please create a separate issue(s) regarding documentation and usability about these problems.