Bug 123272 - FILESAVE DOC(X): Unchecking Protect form compatibility settings returns as checked after save+reload
Summary: FILESAVE DOC(X): Unchecking Protect form compatibility settings returns as ch...
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.0.3 release
Hardware: All All
: low normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:doc, filter:docx, regression
Depends on:
Blocks: DOCX-Doc-Protection
  Show dependency treegraph
 
Reported: 2019-02-08 18:21 UTC by Aron Budea
Modified: 2021-01-26 17:16 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample DOCX (15.94 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2019-02-08 18:21 UTC, Aron Budea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2019-02-08 18:21:03 UTC
Created attachment 149028 [details]
Sample DOCX

- Open the attached simple DOCX created in Word, and the restricted so only forms can be filled.
- In Tools -> Options..., LibreOffice Writer -> Compatibility uncheck 'Protect form', to remove the restriction.
- Save and reload the document.

=> The same compatibility setting is still set.
When opened in Word, the document is restricted, therefore it's an issue during file save.
The same occurs when working with DOC format.

Observed using LO 6.3.0.0.alpha0+ (f8c4459bbda62cb905d0c007cac044f3410ab76b) / Ubuntu 18.04.
No issue in LO 5.4.0.3.

The behavior was introduced by the commit referenced below (checked using repo bibisect-linux-64-6.0). Adding Cc: to Serge Krot, please take a look.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=2694162969cf86ef366d3ce812fccd0630acc800
author		Serge Krot <Serge.Krot@cib.de>	2017-09-29 18:01:54 +0200
committer	Thorsten Behrens <Thorsten.Behrens@CIB.de>	2017-10-06 08:06:59 +0200

tdf#66398 Import/export docx document protection properties
Comment 1 Xisco Faulí 2019-02-11 16:12:38 UTC
Reproduced in

Version: 6.3.0.0.alpha0+
Build ID: 8c0bb7692a5ae3f1c0d1966903baef013b50a7e6
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded
Comment 2 Aron Budea 2019-04-02 01:51:03 UTC
The problem is that the grabbag form protection, if exists, always takes precedence over the Protect form compatibility settings, see the following line, and where hasProtectionProperties is set:

if (! hasProtectionProperties)
https://opengrok.libreoffice.org/xref/core/sw/source/filter/ww8/docxexport.cxx?r=8b5e23ea#1128

I don't know enough on the topic to propose a fix, but what I'd try is:
- if the grabbag contains form protection set, then:
  - if enforcement in the grabbag is off (was imported as such, compatibility option is off at start):
    - if the compatibility option is off => rely on grabbag,
    - if the compatibility option is on => mostly rely on grabbag, but set enforcement,
  - if enforcement in the grabbag is on (was imported as such, compatibility option is on at start):
    - if the compatibility option is off => discard grabbag, don't use form protection,
    - if the compatibility option is on => rely on grabbag,
- if the grabbag contains a different kind of protection (compatibility option is off at start), then:
  - if the compatibility option is off => rely on grabbag,
  - if the compatibility option is on => discard grabbag, use compatibility setting,
- if the grabbag doesn't contain any document protection, then:
  - use compatibility setting.

Justin, does the idea outlined above sound reasonable to you?
Comment 3 Miklos Vajna 2019-04-02 10:59:24 UTC
If doable a much easier way is to just clear the grab-bag when the UI modifies the protect form settings. Unless I missed a detail and this would not solve the end-user problem.
Comment 4 Justin L 2020-02-05 13:00:09 UTC
based on https://bugs.documentfoundation.org/show_bug.cgi?id=123912#c15 this issue is pretty much irrelevant since that flag basically does nothing now.
Comment 5 Justin L 2021-01-26 17:16:26 UTC
This flag is basically irrelevant since a backport to 6.2. Might as well mark as WONTFIX.