Description: The expert settings AllowEditReadonlyDocs and AllowOverrideLocking have been introduced with version 7.0 and seem to have a default value of true, which IMHO is not safe. With LibreOffice installations that have been upgraded from older versions as well as with new installations, the settings have a value of true. Steps to Reproduce: 1.open Expert settings in LibreOffice 2.search for AllowEditReadonlyDocs and/or AllowOverrideLocking 3.check the set value Actual Results: values are true (unless manually changed at an earlier stage) Expected Results: values are false Reproducible: Always User Profile Reset: No Additional Info: The problem became apparent when a user used the override option and prevented the original user to save his changes. After checking https://wiki.documentfoundation.org/ReleaseNotes/7.0 for AllowOverrideLocking I found that AllowEditReadOnlyDocs has the same problem.
On pc Debian x86-64 with master sources updated today, I could reproduce this. I submitted https://gerrit.libreoffice.org/c/core/+/138378 on gerrit. Samuel: put you in cc so you can tell if there was some reason to use true by default. In this case, I'll abandon the patch of course.
Why should they be false by default? This was always possible, the options were introduced to allow locking this functionality down in certain environments. But they should not be locked down by default.
I abandoned the patch, perhaps it should be debated in ESC.
Miklos: would it be possible to add this topic on ESC for tomorrow or it's too late for this one (considering https://lists.freedesktop.org/archives/libreoffice/2022-August/089270.html) and would be next week?
(In reply to Julien Nabet from comment #4) > Miklos: would it be possible to add this topic on ESC for tomorrow or it's > too late for this one (considering > https://lists.freedesktop.org/archives/libreoffice/2022-August/089270.html) > and would be next week? As background information: in the network where I maintain a series of LibreOffice installations it occurred multiple times that when a document was locked by user A, user b chose option 'edit' when informed of the locked state, changed the document and thereby prevented user a to save its changes (or causing a loss of saved changes). The users did not understand the consequences of choosing 'edit', therefore I think that the two Allow options should not be on by default.
Heiko: what do you think? Looks like a UX question, but feel free to take it to the ESC if you think necessary. (But that is effective only in case both Samuel and Winfried are interested in joining the call, otherwise parties with different views can't express their view.)
Agree for readonly documents as editing is pointless. In case of locked files there was some option to get informed and save later. Cannot test this easily.
i belive the way it's supposed to work is that when you click "Edit", the document is reopened and same check happens as when you load a document normally, if it is writable. if it's not writable at this point in time, it should pop up the same dialog with buttons like "Open anyway", "Cancel", "Open readonly", "Notify". so i dont see a problem with this button, and wonder why there's a setting to disable it; perhaps there's an enterprise grade use case for it.
(I was too late to join the ESC.) The behaviour with AllowOverrideLocking seems 'unfair'. User A opens a document for editing that is not locked and assumes (s)he has locked the document for others. Next user B opens the same document, gets a message that the document is locked and chooses to open it (either deliberately or unknowing what the consequences may be), makes changes and saves these. No messages this time, as the lock has been transferred from user A to user B by choosing to open the document. Now user A wants to save her/his changes and finds the document locked by someone else! User A has no other options than disregarding her/his changes and doing them again after closing and reopening the document (in which case the situation between user A and B may reverse when user B still has the document open). The unfairness IMHO is that user A worked prudently but is the victim of inprudent actions of user B and user A has no possibility at all to prevent this. AllowEditReadOnlyDocuments is an analogue case. Someone decides a document should be readonly and (other) users can simply overrule this. I don't question the presence of these settings, just the default value and the fact that 'no one knows about these default values' until an incident occurs. The release notes for version 7.0 (https://wiki.documentfoundation.org/ReleaseNotes/7.0#Config_options) didn't alert me and suggest that new options were added where the default behaviour was changed.
(In reply to Winfried Donkers from comment #9) > AllowEditReadOnlyDocuments is an analogue case. Someone decides a document > should be readonly and (other) users can simply overrule this. No, that's not how editing read-only documents works. See the commit message of <https://git.libreoffice.org/core/+/b9ecec7c74687ed5a9470cffb7d02e0e6e83107e%5E!/> "Allow for editing of read-only documents" for details. (Whatever the take on the comment 0 "Additional Info" about a problematic AllowOverridingLocking scenario, I don't think it is useful to also consider AllowEditReadonlyDocs as an analogous, similarly problematic case in this issue.)
(In reply to Stephan Bergmann from comment #10) > (In reply to Winfried Donkers from comment #9) > > AllowEditReadOnlyDocuments is an analogue case. Someone decides a document > > should be readonly and (other) users can simply overrule this. > > No, that's not how editing read-only documents works. See the commit > message of > <https://git.libreoffice.org/core/+/ > b9ecec7c74687ed5a9470cffb7d02e0e6e83107e%5E!/> "Allow for editing of > read-only documents" for details. > > (Whatever the take on the comment 0 "Additional Info" about a problematic > AllowOverridingLocking scenario, I don't think it is useful to also consider > AllowEditReadonlyDocs as an analogous, similarly problematic case in this > issue.) You're right, AllowEditReadOnlyDocs works differently and documents saved as readonly cannot be overwritten.
Closing this report, given that the behaviour is intentional.