Hi, On 26.06.2012 09:53, Fan Zheng wrote: > 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. >
Thanks for this really deep and well founded analysis. I am currently reviewing the new patch. Best regards, Oliver.
