This is a follow-up of bug 144996
Steps to reproduce:
1. Open attachment 175647 [details] from bug 144996
2. Edit - Edit Mode
3. Introduce the password
4. Modify the file
5. Save to a new document
6. Close the document and open the new document
-> it's possible to edit the new document without the password
Version: 126.96.36.199.alpha0+ / LibreOffice Community
Build ID: bd992ae1228b2f7e556f89f95949da0aeade5b91
CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3
Locale: en-US (es_ES.UTF-8); UI: en-US
Is the bug 142147 about the same?
(In reply to Roman Kuznetsov from comment #1)
> Is the bug 142147 about the same?
I don't think so, this is about read-only protection
I think it is the same, never mind if RO or open password, they are all in the same dialog.
*** This bug has been marked as a duplicate of bug 142147 ***
(In reply to Timur from comment #3)
> I think it is the same, never mind if RO or open password, they are all in
> the same dialog.
> *** This bug has been marked as a duplicate of bug 142147 ***
Then it should be fine if e0cced9d4c94324e834e46d807469a0cd6c1f738 is reverted, which is not the case...
Using XLSX format is not ideal for this bug report. The password protection for the provided example is only imported starting in LO 7.3 with
Author: Tünde Tóth on Wed Sep 1 15:47:40 2021 +0200
tdf#115933 XLSX import: fix permission for editing
For ODS format, this password-protected read-only is imported already in LO 3.6. Even back then a save-as doesn't auto-select password mode. Assuming inherited from OOo.
Yes, this is very similar to bug 142147, but it does not use SID_PASSWORD. In fact, I didn't see ANYTHING passing by that knew this setting was enabled.
I assume it is SID_MODIFYPASSWORDINFO.
The place to bPreselectPassword is sfx2/source/doc/objserv.cxx
The act of requesting a password in this case should be pretty simple. It is the same area as bug 142147.
We have the following functions to work with:
-IsLoadReadonly() // File - Properties - Security - Open File read only
-IsReadOnly() // Is the document currently in read-only mode?
-IsModifyPasswordEntered() // Has the user unlocked edit mode already?
-GetModifyPasswordHash() // one of two ways to require password to modify
-GetModifyPasswordInfo().hasElements() // second way to require edit password.
I'm assuming GetModifyPasswordHash is an old method. During investigation for this bug report, I only saw GetModifyPasswordInfo used.
So the question is "In which situations should we assume the user wants to enter a password?"
Note that "open read only" is hidden under a dropdown, and will ALWAYS start as unchecked. (To change this would be rather tedious I expect.
[The function is passed bIsPasswordToModify, but that only indicates whether to
ENABLE the read-only part of the dialog. It is a LONG calling trail to try to
pass any config options to it...]
Perhaps the easier question to ask is when would you NOT want to save with password.
-obviously one of the two password methods needs to exist
-but not if the user has turned off IsLoadReadonly - verify still active.
-question: is there a way to set Modify Password WITHOUT LoadReadOnly?
-so at this point the document is going to open read-only anyway, the only question remaining is whether it should require a password.
In the spirit of bug 142147, it shouldn't matter whether the user has entered edit mode or not. Since a password exists, it should be suggested at SAVE-AS.
so bPreselectPassword &= IsLoadReadonly() && (GetModifyPasswordInfo().hasElements() || GetModifyPasswordHash())
The downside here is that there is NOTHING that hints to the user why the password is being requested. The read-only portion is minimized, and the read-only flag is off (despite being IsLoadReadonly).
I think the key to fixing this is to get that dialog to expand and default to m_xOpenReadonlyCB->set_active(IsLoadReadonly())
(In reply to Justin L from comment #6)
> I think the key to fixing this is to get that dialog to expand and default
> to m_xOpenReadonlyCB->set_active(IsLoadReadonly())
Doing so requires adding an entry to
It just doesn't seem worth it for this minor annoyance.
While it may not be worth submitting the patch, I decided to try and write it anyway. It seems to work nicely. https://gerrit.libreoffice.org/c/core/+/143312