incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver-Rainer Wittmann <orwittm...@googlemail.com>
Subject Re: Propose for 3.4.1: Can't remove password from file (119366)
Date Tue, 26 Jun 2012 12:05:15 GMT
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.

Mime
View raw message