Root cause:
Seems the logic of "Save As" and "Save" inside Apache OpenOffice is pretty
weird anyway.
A, inside AOO, the method SfxBaseModel::StoreSelf is the entry for storing
file into the original URL path if it has one. Which means, such method is
responsible to:
1. Directly "Save" request, but exclude the very first time on "Save"
without original URL path;
2. "SaveAs" request, with the same URL information as former;
B, as such method is only focus on storing back into to original file, it
is designed as an incremental saving pattern for certain efficient
consideration. Which means,
such function do not allow external saving parameters except the ones on
changing "Version Comments", "Author", "Interaction Handler" and "status
Indicator".
C, "Saving with password" is a kind of external saving parameter. The
saving parameters set will contain a password item inside, if users have
enable the check box
"Save with password" in "File Save As" dialog. Otherwise, saving parameters
set wont contain password corresponding items.
Combine the above 3 conditions, we can take a deeper inside look of
following scenarios:
1. In the "Save" request, whatever the password originally enabled or not,
as no further different setting applied, the storing process will directly
apply the former saving parameters set, including the URL path and password
setting stuff. Everything is OK.
2. And in the "SaveAs" request with password originally disabled:
2.1 If the user keep the "Save with password" disabled in "File Save As"
dialog, as no further setting applied, the storing process will directly
apply the former saving parameters set, still with password disabled. Keep
the consistence between UI setting and exact result and high efficiency;
2.2 If the user change the "Save with password" from disable to enable in
"File Save As" dialog, as external saving parameter was added into saving
parameters set, which do not satisfy the verification of parameters, such
"SaveAs" request will be returned from SfxBaseModel::StoreSelf, and
actually finished inside the common "SaveAs" method with password enabled.
Also keep the consistence between UI setting and exact result;
3. In the "SaveAs" request with password originally enabled:
3.1 If the user keep the "Save with password" enabled in "File Save As"
dialog, as external saving parameter was added into saving parameters set,
which do not satisfy the verification of parameters, such "SaveAs" request
will be returned from SfxBaseModel::StoreSelf, and actually finished inside
the common "SaveAs" method with password enabled. Keep the consistence
between UI setting and exact result, but with lower efficiency;
3.2 If the user change the "Save with password" from enabled to disabled in
"File Save As" dialog, as no further setting applied, the storing process
will directly apply the former saving parameters set, still with password
enabled, as oppose to the UI setting. The issue happens.
So, a reasonable solution of this issue should be:
1. No process and saving parameter change on scenario 1 and 2;
2. In scenario 3.1, remove the external password parameter as the
originally enabled, and makes it finished in StoreSelf for higher
efficiency;
3. In scenario 3.2, do not trying to use StoreSelf anyway;
For you reference.
The code patch will be submitted for reviewing later.
