Description: it would be possible to allow inserting content into fields in a locked section. Currently, it is probably not possible to protect a document with fields against modification, and it is easy to accidentally remove fields. Or does this have a solution? Steps to Reproduce: 1. Insert user fields into the section 2. Lock the section 3. Can't insert data into a user field 4. When a user field is not in a locked section it is easy to accidentally delete it Actual Results: It is not possible to lock a user field against deletion (or format change, or change for another field) and at the same time allow editing of its content Expected Results: Allow editing the contents of a locked field Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 186662 [details] possible design of the form
Kabilo, it's not really clear to me, what do you mean with "User Field". I've added Form -> Text Box and it works. Could you please specify? Thank you => NEEDINFO
Hi, probably this is a bug and the required functionality should be standard: https://bugs.documentfoundation.org/show_bug.cgi?id=149827
Hi Dieter, user fields are e.g. address data in contracts that you want to repeat multiple times. Text box is not a suitable solution for this. Thanks
(In reply to kabilo from comment #4) > Hi Dieter, user fields are e.g. address data in contracts that you want to > repeat multiple times. Text box is not a suitable solution for this. Thanks Could you please attach a short sample document with a protected section and user field? Thank you.
Created attachment 187394 [details] simple example of a field in locked section
Kabilo, thank you for document. Now it's clear to me and I can confirm it with Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 4b3d3354119b643ec20aaad187d0a6506ea307fb CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded I add design-team for decision about a good solution
I hesitate to agree with the requirement. Write protection is exactly meant to protect the content and there are probably many other ways to define a form with static text and some input fields. OTOH, it would be in alignment with Calc where it's possible to protect the sheet but make individual cells writable (with a lot of usability issues as a consequence). Mike, Cor: what do you think?
There are several existing methods to protect/allow editing of the (parts of) text document. They likely don't cover all useful scenarios. Just listing what I recall from the top of my head: 1. File->Properties->Security - allows to password-protect change tracking mode, and open in read-only mode by default (same as in menu Edit->Track Changes). 2. Section: allows lock it; also allows to keep it editable in a read-only document. 3. Tools->Protect Document: allows to protect fields and/or bookmarks. 4. Table: allows to protect/unprotect selected cells. 5. (Obsolete, doesn't work anymore) Options->Writer->Compatibility, Protect form (used to protect the whole document). 6. File->Save As->"Save with password" checkbox: allows to set passwords to open and/or edit document (edit mode password is asked using menu Edit->Edit Mode). We could ask others (Regina is likely the expert here) for other existing features (likely related to respective ODF features). The interested parties should also check how the wanted scenarios are implemented in other office suites, to avoid creation of incompatible implementations, when following an existing model could suffice. Personally I think that, *if* we don't have a reasonable way to do what OP wants, it would be a useful thing to implement (taking into account the above).
(In reply to Mike Kaganski from comment #9) > ... check how the wanted scenarios are implemented in other office suites MSO uses special section breaks, and while I fail to find out how to make those read-only it works similarly when loading the example (cannot focus the field in the protected section). In case of form elements everything works as expected and I still don't see why a field variable needs to be changed in a protected section. My take is still WF. (In reply to Mike Kaganski from comment #9) > There are several existing methods to protect/allow editing of the (parts > of) text document. They likely don't cover all useful scenarios. > ... > Personally I think that, *if* we don't have a reasonable way to do what OP > wants, it would be a useful thing to implement (taking into account the > above). So you agree with the requirement?
(In reply to Heiko Tietze from comment #10) > So you agree with the requirement? Yes. > In case of form elements everything works as expected and I still don't see > why a field variable needs to be changed in a protected section. (In reply to kabilo from comment #4) > user fields are e.g. address data in contracts that you want to > repeat multiple times. [Form field control] is not a suitable solution for this. Please note this important piece. Fields provide many important features, like setting once - showing multiple times; using their values in calculations; allowing the selectable content to be perfectly in line with text, without visual artifacts on printing, etc. These all are useful in documents where one wants to limit users' ability to input to specific parts. I would like this functionality back in the time, when I prepared templates for my users; and I clearly see the advantages in implementing the request.
(In reply to Heiko Tietze from comment #10) > > In case of form elements everything works as expected and I still don't see > why a field variable needs to be changed in a protected section. My take is > still WF. > Imagine documents where the same information appears in several places in the text, including hidden sections. You need the text to be correctly aligned, with no white space. The user cannot change any part of the document, only add values to fields. At the same time, it must not be possible to delete a field!!! In LO It is best to use user fields for this (Ctrl+F2). I have not found an option to resolve the document in this way. Thanks
(In reply to Heiko Tietze from comment #8) > Write protection is exactly meant to protect the content > and there are probably many other ways to define a form with static text > and some input fields. I'm not sure I understand what you mean. As a document author, I may want to protect * just field values, not other content (unlikely, but maybe there's a use case for this); * all content other than field values (very common); * both (somewhat common I guess, conditioned on having fields at all). How, in your opinion, should each of these happen?
We discussed the topic in the design meeting. There are some arguments against such an enhancement: Fields may provide important features, eg. to control hidden parts, but this variable itself does not need to be in a protected area. And while we could show "[ ] Ignore protection" in the field dialog or "[ ] Keep fields editable in case of protection" in the section dialog, the UI solution would be clumsy anyway as an exception for fields is unexpected, at least for the majority. Last but not least there are likely plenty of other solutions. => WF, feel free to reopen.
I, on the other hand, think this behavior is expected. It's similar to a pdf form - you can't change anything - only the content of the fields. The advantage would be a clean text alignment without oversized field lengths in the printed document. Of course there is a solution - I can put all the value entry fields on the first page and start writing ( and printing) the document from the second page, where these fields are already repeatedly inserted into locked sections. Still, I don't know how to prevent accidental deletion of fields on the first page. A suitable substitute is also Mail Merge but ... Let's wait if someone reopens this request. Thanks for your time.