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. 2012/6/25 Oliver-Rainer Wittmann <orwittm...@googlemail.com> > Hi > > On 25.06.2012 13:32, Fan Zheng wrote: > > o, i miss the situation you mentioned. OK, i will keep on working with > this > > issue. thanks a lot！ > > No problem. > I have assigned this issue to you. > I am looking forward to see your solution. > > Best regards, Oliver. > > > 在 2012-6-25 晚上7:11，"Oliver-Rainer Wittmann" <orwittm...@googlemail.com > >写道： > > > >> Hi, > >> > >> On 25.06.2012 10:20, Fan Zheng wrote: > >> > >>> Hi, All: > >>> > >>> This issue was solved, now call for the reviewers. > >>> > >>> In general, this is a setting confusion issue. In current saving > process, > >>> both SID_ENCRYPTIONDATA and SID_PASSWORD are working for setting > password > >>> on a document. > >>> Refer to the SfxObjectShell::ExecFile_Impl(**) in file > >>> SRC/sfx2/source/doc/objserv.**cxx:line 595-599 please. > >>> And, as what we imagine, after doing the file dialog executing with > >>> deselecting the check box of "Save with password", the result parameter > >>> set, which is to customize saving process, wont record said 2 SID > inside > >>> anymore, for indicating that the following saving process will not > concern > >>> about the password stuff anymore. > >>> But when performing the exact preparation SaveAs process in > >>> SfxobjectShell::PreDoSaveAs_**impl(), only the the default SID_PASSWORD > >>> was > >>> cleared, but SID_ENCRYPTIONDATA was not. The issue happens. > >>> > >>> For solving it, we just simply add the item SID_ENCRYPTIONDATA > clearing > >>> in SfxobjectShell::PreDoSaveAs_**impl(), similar as the SID_PASSWORD. > >>> > >>> > >> I have reviewed the patch. > >> Please see my comments in the issue [1] and [2] > >> > >> [1] https://issues.apache.org/ooo/**show_bug.cgi?id=119366#c9< > https://issues.apache.org/ooo/show_bug.cgi?id=119366#c9> > >> [2] https://issues.apache.org/ooo/**show_bug.cgi?id=119366#c11< > https://issues.apache.org/ooo/show_bug.cgi?id=119366#c11> > >> > >> > >> Best regards, Oliver. > >> > > > >
