Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of orwittmann@googlemail.com
 designates 209.85.214.47 as permitted sender)
Message-ID: <4FE9A57B.9040300@googlemail.com>
Date: Tue, 26 Jun 2012 14:05:15 +0200
From: Oliver-Rainer Wittmann <orwittmann@googlemail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: Propose for 3.4.1: Can't remove password from file (119366)
References: 
 <CAP-ksogko9467Af8VNPrQWecUO_1KQtcrAiPke51CRR1ELJxuw@mail.gmail.com>
 <4FE080DB.5050406@googlemail.com>
 <CALHC_o0HZ3V420g42C4y2pE3B8WYrPO+M69-bhGNNjnrQJhydA@mail.gmail.com>
 <4FE84748.2080508@googlemail.com>
 <CALHC_o0mt79vF1h3ZKykuxPA1uz-hWv0c31y0U_LBThgGPQ2Hw@mail.gmail.com>
 <4FE84EFC.3020000@googlemail.com>
 <CALHC_o2jF-eZzmDqGbUu0hK0G7dfdsmv3rCpyJJiJimY1hXk4Q@mail.gmail.com>
In-Reply-To: 
 <CALHC_o2jF-eZzmDqGbUu0hK0G7dfdsmv3rCpyJJiJimY1hXk4Q@mail.gmail.com>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 7bit

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.