Description: This is a feature request. Input list field (ex. "1. cat", "2. dog", "3. pig") appears several times in a document. I would like to click on the first input list field and choose "1. cat" and the same choice would appear in the other list field. Also, if I would like to edit an entry in the first list (ex. I would change "3. pig" to "3.bird", the rest of the field would also make the changes. Steps to Reproduce: Several Input list field appears in a document with similar choices/entry. Actual Results: You have to click/edit each individual input list field to make the necessary changes/choices. Expected Results: Changes in one input list field, also make the same changes to other input list field. Reproducible: Always User Profile Reset: No Additional Info: The request is similar to when you make a change in a variable input field, the variable user field also make the change.
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it)
Created attachment 148250 [details] Screen Shot - Input List Field Here is a screenshot of the request. I hope this clarify things.
Please also tell us your use case rather than the envisioned solution. What I understand is that you insert a field into a document per Insert > Field > More Fields (Ctrl+f2) and Functions > Input List with Items Foo, Bar, Baz => Insert. And now you expect the dialog that shows up on double click on this field to provide means to change the items (maybe at the fields dialog too). As a working alternative you can do Variables > User Field: Name="Foo", Value="Bar". Modifying this to "Baz" applies to all fields in the document. Admittedly not a list but it sounds better suited to your use case. The request sounds not too sensible to me and I'd be afraid of side-effects, eg. when editing a structured document you shouldn't modify the predefined values. Other opinions?
Created attachment 148338 [details] Sample Case Yes. I agree that this can be done using the user/input field in the variable tab. But sometimes you need to just give the end user with a predetermined list of options. Also it would save you time and make you less prone to errors if you just click on the choices, rather than manually type it. In the attached example, it would be convenient to just click on the “names” of the persons and the “floor number,” instead of manually typing it especially if you make several of this documents in a day.
“The request sounds not too sensible to me and I'd be afraid of side-effects, eg. when editing a structured document you shouldn't modify the predefined values. Other opinions?” There may be times when you need to edit the predefined values, as when, in the attached sample, Peter Parker resigns and needs to be replaced by Diana Spencer. I dont know about programming, but I was thinking about We can be allowed to name a list. For example, the names of the employees will be called “List 1” and the floor number, “List 2.” So that any action I do on any one of the “List 1” will be replicated in the other “List 1.” BTW, is there a way to edit the comments We post here?
Okay, lets see if a developer takes this. The solution could be based on the existing "edit" function. That brings you into the field edit dialog where we could add an Edit button next to Add which changes the item selected below according the text at Item. Additionally, the Item should take the content from the list on double-click. Might be an easyhack.
I think the solution does not address my main concern, which is that several list fields are “linked,” so that any action you make in one list field (ex. choosing, deleting, and modifying an entry) will be replicated in the other similar list field. In the sample attached, I click on the “names” and choose “Peter Parker” in the first memo, and “Peter Parker” will be selected in the other two memos. I dont have to manually click the two. Similarly, I click on the “floor” and delete “first and second floor,” and it will be deleted in the two others. However, your solution is a welcome improvement. This is also one of my concerns, which is that the list field lacks an edit button. I was planning to also request for this enhancement. In the current set-up, when you make a mistake in an entry, you have to click on it > edit > remove > re-type it all over in the Item and then click add. This is bothersome especially if you only have minor edits. In the sample attached, if I want to change “and” into “or” in the “Peter Parker, Clark Kent and Bruce Wayne,” I have to remove the said entry, re-type the names all over again with the correct “or” and then click add. Your solution which is to “add an Edit button next to Add which changes the item selected below according the text at Item,” would eliminate this.
(In reply to ibelin123 from comment #7) > I think the solution does not address my main concern, which is that several > list fields are “linked,” so that any action you make in one list field (ex. > choosing, deleting, and modifying an entry) will be replicated in the other > similar list field. Wouldn't implement such a complex and error-prone interaction. The simple Edit button should speed up your workflow significantly. But whether fields are linked or not, and how the modification behaves in consequence, is a manual task. Let's keep it simple.
Ok. thank you for your inputs, although I fail to see why this would be an "error-prone interaction." It would just like be an "input field-user field variable." What you do in an "input field" will be replicated in the "user field" of the same variable. In the feature request, what you do in an "input list" will be reproduced in the other "input list" of the same type. But again, thank you for taking the time to study this request.
As I've described in my talk yesterday (LibOcon 2021) there is a (dirty :) workaround to replicate the choice in other parts of the document: cross references. It's not what requested, as it will just report the choosen value, not the whole input list, but probably could already be an acceptable compromise. To do that, select the input list and then, via CTRL + F2 -> Tab "Cross-references", choose "Set reference". Then use "Insert reference" (and "Reference" in "Insert reference to") every time you need to replicate the user's choice. A side effect is that if a recalled reference is clicked, the cursor jumps to the input list, which could also be not that bad. What is not solved is that there is no storing of such a chosen value, to be used in hiding sections, for instance. And this is the topic of bug 130198 (https://bugs.documentfoundation.org/show_bug.cgi?id=130198).