Now the new patch was updated onto bugzilla, for you review. 2012/6/26 Fan Zheng <zheng.easy...@gmail.com>
> 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. >> >> >> > >> >> >
