[Libreoffice-bugs] [Bug 114246] FILEOPEN: Read-only file is open with design mode enabled.

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Tue Dec 5 19:41:17 UTC 2017


https://bugs.documentfoundation.org/show_bug.cgi?id=114246

--- Comment #8 from Lionel Elie Mamane <lionel at mamane.lu> ---
(In reply to Xisco FaulĂ­ from comment #6)
> once the document is changed to non design mode,
> it will remain like that forever,
> but you can't expect all users to know that.

> This kind of documents with forms are usually sent to many other users,
> and if it's sent in design mode and not everyone will be able
> to switch to non design mode.

My point was that only _ONE_ person needs to "know that" and "switch to
non-design mode": the person designing the form, and sending it to many other
users. I think we can expect a higher level of knowledge from a person
designing a form, and sending it to many other persons, than from the many
other persons that get the form and are only supposed to fill it in.

To my ears, "if it is sent in design mode" sounds like "if it is sent
read-write instead of read-only". Why do we expect the sender to know about the
"open in read-only mode" bit in file/properties, but not about the "open in
non-design mode" bit in the forms toolbar?

(In reply to Heiko Tietze from comment #7)
> The question is whether a document is automatically saved in non-design mode
> and users have to enable the edit before working on the forms design.

No. The question is whether a document that is saved in read-only mode should
also be opened automatically in form non-design mode, even though it is
configured to open in form design mode (that is, the office:forms element has a
attribute form:apply-design-mode="true").

> If edit is off, neither design nor input is possible.

That is not the current situation, AFAIK never was, and is contrary to my
understanding of the use case. My understanding of the use case is:

 * one person, a more technically knowledgeable one, designs the form.
   I call that person the "designer".
 * The designer "finalises" the form document and sends it to many other
persons
 * the many other persons fill in data in the form (what you called "input")

The discussion is what the designer has to do to "finalise" the form. My
understanding of the use case is that the designer sets the document to
read-only (so that no change OUTSIDE OF FORM ELEMENTS can be done), in order to
"force/encourage" the many persons to put their data IN THE FORM ELEMENTS and
not in the document itself (which will not work if the form is HTTP-submitted,
or writes to a SQL database, etc).

So it is critical to this use case that data entry in the form (input) is
allowed when the document is in read-only mode.

What Xisco is asking is that the "finalisation" of the document by the designer
consist only in one step, namely:

1) go to menu file, properties, tab "security", check "open file read-only"
   this sets, in settings.xml, "LoadReadOnly" to the boolean "true".
then save the file, send it to many people

The situation now, since 2014, is that the finalisation requires _two_ steps:

1) go to menu file, properties, tab "security", check "open file read-only"
2) in the "form design" toolbar, click on the "open in design mode" button,
   so that the button is no pressed.
   this sets the form:apply-design-mode="true" attribute in the forms element
in content.xml
then save the file, send it to many people

I made a quick test, and it seems that "open in non-design mode" is the DEFAULT
SETTING for new documents. So it seems that step 2 IS NOT NECESSARY, unless the
designer EXPLICITLY SET "open in design mode" at some point in the past. My POV
is that if the designer has EXPLICITLY SET the form:apply-design-mode="true"
attribute, that should be respected, even if in settings.xml, LoadReadOnly is
true.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20171205/9e138aa8/attachment.html>


More information about the Libreoffice-bugs mailing list