https://bugs.documentfoundation.org/show_bug.cgi?id=164013
--- Comment #4 from Christopher R Lee <[email protected]> --- (In reply to george from comment #2) > (In reply to Eyal Rozenberg from comment #1) > > (In reply to george from comment #0) > > > > Data validation is itself a form of partial protection from editing. Does it > > really require a protection-of-itself? That seems a bit weird. > > > > Protecting the format sounds interesting. > > > > Could you present a compelling use-case for these kinds of protection? > > I think a good use case is a spreadsheet template that is distributed to > many users as an input form. > > For example, an organization may have a template where users need to enter > information such as department, language, status, date, etc. A cell for > "Language" might have a data validation list containing only "English" and > "French". The users should be able to edit the cell and select one of those > values, but they should not be able to modify or remove the validation rule > itself. > > The same applies to formatting. The template may have specific formatting > for input cells, dates, mandatory fields, calculated fields, and so on. > Users need to edit the data, but they should not accidentally change the > formatting or the rules that define how the data should be entered. > > A common way this breaks is when a user pastes content from another source – > the paste operation overwrites both the value and the validation > rule/formatting. This happens unintentionally all the time and is the main > reason why simple "unprotected cells" are not sufficient. > > I think this is an important distinction: protecting the cell content and > protecting the rules governing the cell are two different things. Data > validation restricts what the user can enter, but it does not protect the > validation rule itself. A user who is allowed to edit a cell can potentially > change or remove its validation, which defeats the purpose of having a > controlled input field in the first place. > > A practical scenario would be a template created once and then used by > dozens or hundreds of people. The template designer needs to retain control > over the structure, formatting, formulas and validation rules, while the end > users need to be able to edit only the intended input cells. > > This is also relevant for Excel compatibility. In organizations using > Microsoft 365 and Excel online, this kind of protected template is quite > common. When such a file is downloaded as XLSX and subsequently edited in > LibreOffice Calc, preserving this distinction between editable data and > protected cell configuration becomes important. > > So the desired behavior is not simply "make the cell read-only". It is: > > Users can edit the value of the cell, but cannot modify the formatting or > the data validation rule associated with that cell. > > I believe this would make the feature useful not only for security, but also > for preventing accidental changes and maintaining the integrity of > spreadsheet-based forms and templates. This issue dates from 2012 at the latest and it's one of a couple of things that continue to prevent widespread use of LibreOffice, even in very small associations and enterprises, a serious matter in the present world IT context. A while ago, WPS Office (subscription needed for full version) featured a popup joke about it. -- You are receiving this mail because: You are the assignee for the bug.
