Created attachment 149846 [details] A screen cast of Input Field Reference edit problem When an Input Field (from Variables tab) in created, its Reference (awkwardly named prompt string) may be set in the dialog. After creation, the field allows arbitrary input in it, e.g. by clicking at it, using a dedicated dialog where both Reference string is shown (read-only), and a box for the string. On the other hand, right-clicking the field and choosing "Edit Fields..." context menu, opens a dialog looking just like the initial dialog used for its creation, where there's a "Reference" edit box, with the string initially set into the Reference string. However, editing that "Reference" string in fact changes the Input Box text, while the reference stays unchanged. This is (1) inconsistent (controls suggest that they would modify something else than they actually do), and (2) makes Reference uneditable after creation - user can only re-create the field if one needs to change the Reference string. This is reproducible with Version: 6.2.2.1 (x64) Build ID: fcd633fb1bf21b0a99c9acb3ad6e526437947b01 CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: CL and also even with OpenOffice.org 1.0.3.
(In reply to Mike Kaganski from comment #0) > However, editing that "Reference" string in fact changes the Input Box text, > while the reference stays unchanged i can confirm this behaviour.
Can repro in 6.5.0.0.alpha0+ 1. Can we change the name for "Reference" to something like "Query" ? (because it seems that this field is used for asking some kind of question (sometimes implicitly such as "email address"). 2. Rename the dialog box to (something like): "Response" (instead of "Review Fields") (can there be more than one field) (which would fit with Query) 3. Drop the "edit"-like field after Reference and just show the "Reference" value. (as best I can tell, there is never a need/function to edit that field in that dialog box, so seems better not to suggest/imply that it can be edited). Does not solve the control problems, but might reduce some of the user confusion about the existing function.
One more proposed modification of the "Review Fields" Dialog: to put a label above the "input" field. Something like: "Response" or "Input"
(In reply to Mike Kaganski from comment #0) > (2) makes Reference uneditable after creation - user can only re-create the > field if one needs to change the Reference string. Please forgive me, if I am telling you what you already know but.... A. To edit your creation. 1. Select the field where you want to change "Reference". 2. Use Variables Tab (not right-click, Edit field, but Insert - Fields - More Fields, etc.) 3. Change value of "Reference" 4. Click Insert, then click OK on the "Review Fields" dialog box Now you can double click on the field to confirm that you have changed what appears in the "Reference" field in "Review Fields" B. My explanation/hypothesis. Reference has two different meanings here. In the Edit field dialog, "reference" = value of the variable assigned to the field. (which is how you can change the value shown in the field) In the "Review Fields" dialog, "reference" = "a message to the user" and this is controlled by the "reference" in the Variables tab. My suggestion to rename that "Reference" to "Query" in comment 2 would help to reduce some of this misunderstanding. Beyond that -- you have probably seen that the work flow is a little clumsy here. Maybe the "Apply" button could be used (and make more sense than "insert") -- but it is greyed out in my version -- and without popping up the "Review Fields" window. (because the value is visible in the Field dialog box, so no need for review!)
Dear Mike Kaganski, 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