Created attachment 126918 [details] design ideas how to continue fulfilling input fields Would it be possible to continue fulfilling fields from particular position in Writer template? Currently SHIFT+CTRL+F9 starts from beginning. Let's suppose there was an interruption and would like to continue fulfilling from the place it was interrupted. This is especially important when there is a long document and lots of fields. It would be quite annoying to start from the beginning even there are possibly some fields in the end only to fulfill. Sometimes I would like to change just some field content and not walk through all fields. It would be also appreciated if there could be possibility to move also backwards, not only forwards when fulfilling fields. If there could be even field navigator possible so I could jump to specific (yet unfilled) field directly, would be especially appreciated. If that field navigator could show me which fields are yet unfilled, it would be easier to follow that all fields are fulfilled or at least got attention whether they would be needed fulfilled or not. Also if I double-click on the field - currently I can change only the field title (and move backwards/forwards between field titles) but would like to change also the field content and also move backwards/forwards between field contents plus including that previous idea that there would be an opportunity to jump to specific (yet unfilled) field Investigated: https://help.libreoffice.org/Writer/Fields https://help.libreoffice.org/Writer/Adding_Input_Fields - this tells that SHIFT+CTRL+F9 to start fulfilling fields but not how to continue partially fulfilled fields
Thanks for your comments and the attached design ideas document. Personally I would like to merge the input field edit and the edit dialog. Main problem: there are many more different fields, and the edit dialog adapts to them. And I just realized you can just navigate through the same type of field using the edit window - hmmm... OTOH most time you would just change the input fields manually, so the input field edit dialog is much more convenient here. And there seems to be no way to get any overview of the fields in the document, so probably it's time to expand the edit dialog - it already wastes a lot of space in the left column. Fields are also missing from the normal navigator (F5). It should be easy to add a "previous" button in the "input field" edit dialog. And I just realized "Ok" does the same the "Next", or am I missing something? BTW: since some 4.x (x >= 2) release, you can edit the input fields directly. A single click marks the content off the field and puts the cursor at the end of the field, so you can directly replace the content. A 2nd click allows you to place the cursor anywhere in the field, or just use the arrows. Tab and Shift+Tab can be used to go to the next or previous input field, as long as you are inside. Inside is indicated by a black margin around the field.
Yes I know that I can edit fields manually but using the dialog window would ensure that no one field is missed during fulfilling them. That would be also good idea to make fields viewable in Navigator (F5).
Sorry for being so late at the party. Meanwhile we have the expected "Previous" button in the edit field dialog. The second idea with the Navigator-like list of content sounds wrong to me. From the help: "The value of a variable in an Input field is only valid from where the field is inserted and onwards. To change the value of the variable later in the document, insert another Input field of the same name, but with a different value. However, the value of a User Field is changed globally." Meanwhile a lot work has also been done for the Navigator itself. You get a list of all fields and you see what value it has assigned. So I think your ideas have been implemented. Please feel free to reopen or to submit follow-up tickets.
Sorry but just closing with future ideas does not solve the issue. That's a pity, that this issue is so long time unsolved but hopefully something is happening now and we will get a solution. Currently (also tested with current latest LibreOffice Writer 7.5.3) I can just add fields but later don't see the list of added fields and cannot edit (fix) them. Under right-click menu I can choose to edit field but only partially can change it. To fully fix already inserted field I have to completely re-enter everything and then correctly. This makes a lot of hassle and isn't the way we expect it should work. We would expect fully editable list of inserted fields and we want to fully change them whenever necessary. I can manually double-click on certain filed to fulfill or change already filled content but current bug report is more targeted to find a solution, where we can continue, where we left off. This means, Writer should detect, which fields have already data inserted and which not and then continue, where it left off. Also when checking fields by activating them via SHIFT+CTRL+F9, there would be good to have ability to delete certain field if I decide it is not necessary, sometimes there are some fields really not necessary, e.g. accidentally inserted (empty), etc. In text I don't even see that field but invoking field reviewing via SHIFT+CTRL+F9 to fulfill fields I see that field - now I don't have a way to delete it as I don't even see it in document. A delete button would be helpful; also a button that allows to replace field with regular text. Sometimes I decide that we don't need field anymore but want same text as currently seen in field, inserted directly as text, without field.
(In reply to Edmund Laugasson from comment #4) > Currently (also tested with current latest LibreOffice Writer 7.5.3) I can > just add fields but later don't see the list of added fields and cannot edit > (fix) them. The Navigator (F5) is a handy tool here. Point is we have next/prev in the fields dialog, as requested. And adding a large list next to the dialog sounds wrong to me. => WFM
OK, Navigator is really better than list in editing field dialog. But when opening field editing via Navigator, the button Edit is greyed out in that field editing dialog. I can change only field window title but not content. I assume that edit button should allow to edit also field content. Then I have directly in text open the field dialog box in order to change the content - this is actually already fulfilling field. Would be more logical, when opening field editing via Navigator, there is truly all field elements possible to edit. Certainly editing field opens always same field editing dialog, where that Edit button is greyed out. Anyway, to come back to initial issue, I proposed design ideas. At the end of page 3 there is a design idea, which corresponds to current bug report most. I understand, that in Navigator we see fields but opening its editing should offer to edit all field elements as proposed at the end of page 3 in attached PDF-file. Showing fields in navigator does not solve field editing issues we currently have. To precisely correspond to current bug report topic, there could be separate shortcut key to continue fulfilling fields, where it left off last time. This means that Writer should determine, whether field is fulfilled or not. Currently it is misleading, that editing example text in field goes via opening field for fulfilling. If there could be distinguish editing and fulfilling field, also continuing fulfilling fields could be solved. Try to imagine a situation where you have lots of fields in same document. Then continuing to fulfill those fields on next time is painful as there is no indication, where fulfilling were left off. The easiest solution could be shortcut key but certainly there should be at least one way to continue without knowing that shortcut key. E.g. in Navigator there could be so, that already fulfilled fields are normal but not yet fullfilled are with bold font. There would be expected also under mouse right click menu a choice "Mark not filled" - this is necessary to mark certain fields not filled again, e.g. despite fulfilling field, user decides this should be fulfillable again. Certainly also bulk marking should be possible, e.g. marking all or certain fields via Navigator and change unfilled them. This means Navigator should allow to select more than one field - currently Navigator does not allow that. Marking a field unfilled should pertain its content. Unless in editing dialog the content is changed but filled status is not touched. When opening fields in Navigator, there should be near fields category a small button, which allows to continue fulfilling fields where it were left off.
> Marking a field unfilled should pertain its content I mean marking field unfilled should not change its content, keep existing content.
(In reply to Edmund Laugasson from comment #6) > OK, Navigator is really better than list in editing field dialog. But when > opening field editing via Navigator, the button Edit is greyed out in that > field editing dialog. Edit works for me (double-click is Go To, right-click context menu offers Edit). Version: 7.5.1.2 (X86_64) / LibreOffice Community Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 (In reply to Edmund Laugasson from comment #6) > Anyway, to come back to initial issue, I proposed design ideas. At the end > of page 3 there is a design idea, which corresponds to current bug report > most. You list all fields in the left pane and replace by that the currently shown type of the field. I actually like this idea as a) the left pane looks a bit orphaned with always just one entry, and b) it follows the basic idea of the dialogs in general. What do you think, Mike & Jim. Can we list all fields in the left pane of the (edit) fields dialog?
(In reply to Heiko Tietze from comment #8) > (In reply to Edmund Laugasson from comment #6) > > OK, Navigator is really better than list in editing field dialog. But when > > opening field editing via Navigator, the button Edit is greyed out in that > > field editing dialog. > > Edit works for me (double-click is Go To, right-click context menu offers > Edit). Please note the very clear "Edit is greyed out in that *field editing dialog*", which is completely unrelated to the "Edit" in a context menu, but is about bug 137298.
(In reply to Mike Kaganski from comment #9) > Please note the very clear "Edit is greyed out in that *field editing > dialog*", which is completely unrelated to the "Edit" in a context menu, but > is about bug 137298. Noted. Sorry that I missed the editing _dialog_ aspect. But how about listing all fields in the document rather than just the current one?
IMO, the page 3 suggestion is confusing, and the use case is 100% handled by Navigator providing exactly the same functionality. Having the set of items in a dialog, *other* than the currently selected object, is counter-intuitive. The existing arrows already break this "I edit what I select" paradigm, but at least it replaces everything in the dialog, and make a jump in the underlying document, to make the change obvious, and the *button* UI there is analogous to other things like "apply and find next" in e.g. "Find & Replace".
I understand bug 137298 but as mentioned, editing all field elements are not currently possible. That edit button could allow that. Currently we need delete field and insert it again in order to change all elements. Listing all fields is happening already in Navigator. Page 3 suggestion is not confusing but probably misunderstood. The same dialog will be opened either via mouse right-click+Edit or Navigator right-click+Edit. The page 3 suggestion describes that window, which will be opened when using Edit choice. It would be overwhelming to open every time same way Edit. Therefore there is same list of fields as in Navigator but you can then browse all fields in current document and directly edit them without reopening editing dialog per field. This "I edit what I select" paradigm might sound cool and can still remain as it is. But when editing a document with lots of fields, such paradigm suddenly isn't so cool after all as it will consume lots of time always reopen editing dialog per field. If you have few fields, you can survive but in case of many fields you probably lose too much time.
The Edit button becomes enabled with fields of type ExtendedUser, for example Sender where you can change the information from name to company. All other fields might have an impact on the document and should remain static. So I propose to hide the Edit button unlike to disable it. And keep the dialog as it is.
We discussed the topic in the design meeting and agreed to hide the button if not applicable rather than disabling it.