Created attachment 162226 [details] Sample document The name of the function "Edit fields" and the sketchy help pages (like https://help.libreoffice.org/6.4/en-GB/text/swriter/01/04090300.html?&DbPAR=WRITER&System=UNIX) implies you should be able to edit a field you have inserted. You can't: you can't change the text definition and you can't change the name of the variable. Clicking on a variable in the Select pane of the Edit Fields panel doesn't let you change its Name. Also, if you copy a field from one Writer document into another document, you can't even change the Value. See attached document. Thanks.
(In reply to Luke Kendall from comment #0) > The name of the function "Edit fields" and the sketchy help pages (like > https://help.libreoffice.org/6.4/en-GB/text/swriter/01/04090300. > html?&DbPAR=WRITER&System=UNIX) implies you should be able to edit a field > you have inserted. Help says: "When visible, opens a dialogue box to edit the contents of the field.". In case of a variable it is grayed out, so I think, help is correct here. An I assume, that there are some reasons, why you can't edit a variable.
(In reply to Dieter from comment #1) > (In reply to Luke Kendall from comment #0) > > The name of the function "Edit fields" and the sketchy help pages (like > > https://help.libreoffice.org/6.4/en-GB/text/swriter/01/04090300. > > html?&DbPAR=WRITER&System=UNIX) implies you should be able to edit a field > > you have inserted. > > Help says: "When visible, opens a dialogue box to edit the contents of the > field.". In case of a variable it is grayed out, so I think, help is correct > here. An I assume, that there are some reasons, why you can't edit a > variable. @Luke, do you agree with Dieter's comment ?
I don't really agree, even though you /could/ read the words to mean that. The words would be clearer if they said "Unless the field is greyed out, ..." but that still leaves the key issue: you can't edit them. As it stands the help and the functionality together produce a Catch 22: - you can edit the things when they're not greyed out - they're always greyed out, so in practice you can't edit them
I'm not sure now, if your aim is, that 1) LO help is improved => change component to "Documentation" 2) LO gives you the possibility to edit variable fields => This would be an enhancement request I think
(In reply to Dieter from comment #4) > I'm not sure now, if your aim is, that > 1) LO help is improved => change component to "Documentation" > 2) LO gives you the possibility to edit variable fields => This would be an > enhancement request I think Waiting for a response
My preference, because it would be useful to be able to edit a field, would be to make the bug an enhancement (to provide the implied functionality). My 2nd preference, if that can't be done, would be to clarify the documentation to explain you cannot edit a field, despite the fact that the functionality appears to have been planned.
(In reply to Luke Kendall from comment #6) > My preference, because it would be useful to be able to edit a field, would > be to make the bug an enhancement (to provide the implied functionality). I guess renaming is prevented in order to protect the user from making mistakes, shooting themselves in the foot. Let's ask UX what they think. There is bug 111888 for a variable UX overhaul
(In reply to Buovjaga from comment #7) > (In reply to Luke Kendall from comment #6) > > My preference, because it would be useful to be able to edit a field, would > > be to make the bug an enhancement (to provide the implied functionality). > > I guess renaming is prevented in order to protect the user from making > mistakes, shooting themselves in the foot. Let's ask UX what they think. > > There is bug 111888 for a variable UX overhaul I'm not sure in what way it could lead to causing the user to create errors, but even if there were, I'd hope the function could either: 1) check and adjust to use the new edited value wherever it was previously used, or 2) offer to create a new field with the new properties. In either case, if there's only a single use, I suspect no errors could be caused. But you would all know better than me about the consequences and effects.
(In reply to Luke Kendall from comment #8) > I'm not sure in what way it could lead to causing the user to create errors... You may have a reference to the variable like Section1 visible if Test is 1. Renaming requires to reverse parsing all references, which may cause some trouble. I'd rather reconsider the workflow and question why renaming is needed. Guess something like "Test" going into "Productive" later. The help is clear on what you can do, and the UI too with disabled controls.