Description: I created an Input Field Variable "P." Also there are conditional Variables where P=="A" then "Apple" P=="B" then "Banana" P=="C" then "Citrus" When you open the attached sample it is already pre-selected to "B" and the conditional variable is already "Banana." The problem is when you change the input variable "B" into "C" it will not work but the conditional variable will change into "Citrus." When you save the document: a. in 6.4, it will change to "C" and the conditional variable will remain as “citrus.” b. in 7.1, it will remain as “B” and the conditional variable will return to “banana.” Steps to Reproduce: 1.Click on Input Field already set to "B" 2.Enter a choice "A" or "C" Actual Results: 1. Input Field will remain "B" Expected Results: 1. Input Field should change into "A" or "C" Reproducible: Always User Profile Reset: No Additional Info: I see this problem in 6.4, 7.0 and 7.1, but is not a problem in 6.3 and below. Additional Information: In 6.4, the input variable will not show “input field” when the View Field Names is ticked. In 7.1, when the cursor is placed in the beginning of the input variable and you will double click it, it will open the dialog for an input list which was already deleted.
Created attachment 169487 [details] sample
Confirmed Version: 7.1.0.3 (x64) / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 4; OS: Windows 10.0 Build 21296; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL
Confirmed also: Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 6ca7be8f10deb75399377f25277b943af40f72f1 CPU threads: 4; OS: Windows 10.0 Build 21296; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL Versión: 6.3.5.2 (x64) Id. de compilación: dd0751754f11728f69b42ee2af66670068624673 Subprocs. CPU: 4; SO: Windows 10.0; Repres. IU: GL; VCL: win; Configuración regional: es-ES (es_ES); Idioma de IU: es-ES Calc: threaded With all, [F9] or Menu/Tools/Update/Update fields, update correctly the values.
[F9] for me in 7.1.03 reverts back to the old value. Input Variable is still "B" and the conditional value will return to "Banana."
> Additional Info: > I see this problem in 6.4, 7.0 and 7.1, but is not a problem in 6.3 and > below. Update: Problem is also found in 6.3, but not in 6.2.
Dear ibelin123, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 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: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
adding possibleRegression because of comment 5
This seems to have begun at the below commit in bibisect repository/OS XXXX. Adding Cc: to Samuel Mehrbrodt ; Could you possibly take a look at this one? Thanks 935de3f70961ba8ef6c5282f6f0e4808a49faa78 is the first bad commit commit 935de3f70961ba8ef6c5282f6f0e4808a49faa78 Author: Jenkins Build User <tdf@pollux.tdf> Date: Mon Apr 8 17:15:15 2019 +0200 source 742baabbe4d077e1ba913a7989300908f4637ac7 69414: tdf#123968 sw: use inline editing for input fields for variables | https://gerrit.libreoffice.org/c/core/+/69414 Also after this commit I have to double-click field to edit it. Before single click was sufficient.
(In reply to raal from comment #8) > This seems to have begun at the below commit in bibisect repository/OS XXXX. > Adding Cc: to Samuel Mehrbrodt ; Could you possibly take a look at this one? > Thanks > 935de3f70961ba8ef6c5282f6f0e4808a49faa78 is the first bad commit > commit 935de3f70961ba8ef6c5282f6f0e4808a49faa78 > Author: Jenkins Build User <tdf@pollux.tdf> > Date: Mon Apr 8 17:15:15 2019 +0200 > > source 742baabbe4d077e1ba913a7989300908f4637ac7 > > 69414: tdf#123968 sw: use inline editing for input fields for variables | > https://gerrit.libreoffice.org/c/core/+/69414 > > Also after this commit I have to double-click field to edit it. Before > single click was sufficient. That commit was (mostly) done my Michael Stahl.
Un-CCing developer, its unclear if we can find the time to look into it at this stage.