Created attachment 138217 [details] sample document Steps to reproduce: 1. Open attached document 2. Try to write something in the forms. Observed behaviour: it's not possible as the design mode is enabled. It should be disabled instead. Reproduced in Version: 6.1.0.0.alpha0+ Build ID: 889c72a7e54f241342f42b1b0a05858902228cbc CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: ca-ES-valencia (ca_ES.UTF-8); Calc: group threaded
Regression introduced by: author Lionel Elie Mamane <lionel@mamane.lu> 2014-08-27 18:34:02 +0200 committer Lionel Elie Mamane <lionel@mamane.lu> 2014-09-02 11:16:04 -0500 commit b3062ae65fc7069442cb5fc23dd68c2e8344e999 (patch) tree e3708580a152a9285b6bc1cde2ed810430b3f7da parent 33927ae1208766d6fdb40fdc700afbe10ca91647 (diff) fdo#44081 don't remove 'edit' pop-up menu entry from form in design mode Bisected with: bibisect-44max Adding Cc: to Lionel Elie Mamane
Created attachment 138218 [details] correct "works for me" sample document if you want the form to open in non-design mode, then configure it so. Having the document read-only is orthogonal (independent). I attach an example.
Created attachment 138219 [details] screenshot where to click to configure document to open forms in non-design mode
Yep, I know it can be changed, but the user needs to go to 'Edit mode' and then, change it. My question is: should the design mode be disabled by default if the document is read-only ? I've seen users having problem filling the forms because of this and from my point of view, it should be disabled by default. Adding UX team for a third opinion
For full clarity: The user needs to go _once_ in edit mode, configure the document to open forms in non-design mode, save the document, and from then on the "problem" is solved _forever_ for this document. Or do that at the same time he sets the document to open in read-only mode. Indeed, before 2014 my patch, read-only document had form design mode artificially forced to off. Since these are two orthogonal (independent) settings (and behaviours), it seems clearer and easier to me to understand what happens if they are kept orthogonal. Maybe that's too geeky a worldview, and I'll respect the UX's team opinion on that. *But* note that just reverting the relevant hunk from my patch (file svx/source/form/fmview.cxx method FmFormView::Init) will create problems for Base form documents (which are Writer documents embedded in an odb container). That is because Base form documents do _not_ have a switch to go to edit mode once they are in read-only mode _unless_ they are in "form design mode". So forcing form design mode to off in read-only mode leads to an inescapable situation where the form document can never be edited again. See bug 44081 for that. Maybe we could do it the other way round for Base form documents: ignore their read-only property when they are open in edit / form design mode. That could be workable and give another (quite natural) way out of the inescapable situation.
Hi Lionel, Yep, it's true 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. I just think disabling this in read only would make things easier to the users. OTOH, I agree with you we can't revert b3062ae65fc7069442cb5fc23dd68c2e8344e999 as it would introduce bug 44081 again, and that's is not acceptable. It would be ideal if we could fix this issue while keeping bug 44081 fixed as well.
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. Would agree assuming most work is done in one session and since users who need to edit the design are rather able to switch into this mode than users who enter data into the final design. Ideally we decouple edit and design modes. Documents should be read-only (use case is when many documents are open but only one is to modify), with the simple on/off switch (see bug 86303 for a recent discussion to bring this into the statusbar). The design mode can be on/off when editing is enabled. If edit is off, neither design nor input is possible. Today the two functions are somehow related, as stated by Linonel, and edit on switches the design mode.
(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.
(In reply to Lionel Elie Mamane from comment #8) > > If edit is off, neither design nor input is possible. > > That is not the current situation, AFAIK never was... But it should be. The confusion results also from the mixture of readonly and design on/off. If the RO mode is required to not edit the captions, we could do this internally but make edit on/off more consistently. Other than that I agree with you that we can expect a form designer to know how the finalization has to be done. So no auto switch from design into edit mode on save makes sense.
*** Bug 117219 has been marked as a duplicate of this bug. ***
I can follow Lionel's arguments. Should we resolve as WF, Xisco?
Since DesignMode=on is saved in the document, it is a property that must be honoured on import. Using it puts the burden on the developer to turn it off when it is no longer appropriate. (Developers should test their work before handing it out to be used.) An end user having trouble filling out a form should first complain to the person who designed the form - so that the form is fixed.