When opening a read-only document the systems shows a yellow bar at the top with the caption "This document is open in read-only mode." In addition there's a button "Edit Document" which will allow editing of the document. In our UNO extension we don't want to allow the user to edit the document no matter the circumstances. It should therefore be possible to configure LO in a way, either by configuration item or via UNO API to disable the default behavior. The code in question is in viewfrm.cxx: SfxInfoBarWindow* pInfoBar = AppendInfoBar("readonly",SfxResId(STR_READONLY_DOCUMENT)); if (pInfoBar) { VclPtrInstance<PushButton> pBtn( &GetWindow(), SfxResId(BT_READONLY_EDIT)); pBtn->SetClickHdl(LINK(this, SfxViewFrame, SwitchReadOnlyHandler)); pInfoBar->addButton(pBtn); }
I confirm this is a problem for - external forms, which are linked to a Base-file. - reports of the Report-Builder in Base. The readonly infobar doesn't appear in internal forms of a database-file. So it could be disabled somewhere. Why shouldn't it be defeatable in external forms. Normal users wan't to input content to the forms and don't have to change the form. When executing a report the readonly infobar also appears. A report should be designed well so there musn't be changed anything afterwords. Normal users would be confused when have a look on the editalbe report with all the tables inside. So the edit-mode should only be reachable here through Edit > Edit Mode.
I can confirm the problem. Users of database applications do not need this notice, write-protection of forms and reports is wanted. The popup should be disabled so as not to confuse them and disrupt their work.
I have created an application that uses writer documents as forms. These documents are protected from accidental changes by activating the read-only option. Now the infobar appears to the users of the application and I have to look for an alternative to protect those documents. In my opinion the configuration must include a section to disable the infobar.
(In reply to Luis from comment #3) > I have created an application that uses writer documents as forms. > These documents are protected from accidental changes by activating the > read-only option. > Now the infobar appears to the users of the application and I have to look > for an alternative to protect those documents. > In my opinion the configuration must include a section to disable the > infobar. This is a valid use case. The infobar should *not* appear when the user deliberately sets it as readonly (via doc attribute). Will see if I can fix this.
(In reply to Samuel Mehrbrodt (CIB) from comment #4) I don't know all the cases where a document is identified as read-only. Certainly, the case in which the user expressly marks the option in the document (File -> Properties -> Security -> Open file read-only) the infobar should not appear. I think this behavior would be fully satisfying and would make unnecessary a configuration option to disable the read-only infobar.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=aa8efc72d43c2000cb3b5571fdc6b48617eb9b94 tdf#101652 No infobar when doc attr is readonly It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Please test the daily build once available and report back if the issue is really fixed. @christian.rufener: Would this also fix your use case or do you need something else?
I open the documents with UNO API in read-only mode, so I assume this should work. Nevertheless, I will need to perform a test on this. I'll come back with feedback later.
I've tried the patch and it works perfectly: Create a new writer document. Go to File -> Properties -> Security. Set "Open file read-only". Save and Close. Reopen and there is no infobar. I have also tried other situations (I can not think of more): 1) Set file attributes in SO to read only. When opening the document the infobar pops as expected. 2) Open document in another PC. When opening in my PC pops a message box that says "document file 'xxxx' is locked for editing by". There is a button that says "Open Read-Only". I press the button and the file is open in read-only mode but no infobar appears. So the infobar only is used in case 1. Thank you very much. For my part I am satisfied. I would like to draw your attention to the bug 45313.
Could also confirm it solves the problem in Base-reports. Well done, Samuel.
When I opened Bug 106366 I wasn't aware of this one until it was bibisected. For me, it looked like a regression. Reading here, I'd still be glad to have a fine explanation.
(In reply to Timur from comment #11) > When I opened Bug 106366 I wasn't aware of this one until it was bibisected. > For me, it looked like a regression. Reading here, I'd still be glad to have > a fine explanation. Yes it is a regression. The infobar should not be displayed when a user sets the document as readonly via document properties. in all other cases it should be shown.
unfortunately the behaviour described by the topic opener, is still the same here (LibreOffice 6.3.4.2). the documents are opened by a uno api call like this: propVal[0].Name = "ReadOnly"; propVal[0].Value = new Boolean(true); loadComponentFromURL(sURL, "_blank", 0, props); can you please provide me either with the information, how to disable the infobar or how to set the value of "File->Properties->Security->Readonly" from within a uno call. wenn "File->properties->Security->Readonly" is set, the bar is not shown... Another solution would be to dispatch the command, that is sent by the "infobar-edit-button". Unfortionately this command seems not to be the same, what is send by the Edit-Menuitem (.uno:EditDoc). I am not able to find out any command sent by the edit-button (from the info bar) at all?!
Hello there, we currently have an issue related to this bug. We want to disable the read-only infobar and especially the edit button. We tried it in a manner like comment#13 with different office versions (5.0 - 6.4.2) Although the infobar color changed from yellow to blue and got a pretty little info-icon, the result is always the same: it does not work. Some documents are meant to be ready-only. Being abled to press the edit button leads to weird behaviors and unsolveable problems. It would be great if someone could take a look at this bug again :) regards devTeam4
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/79b578b7f8b5e3a80fcd0fd86e83d96d7c900bb1 tdf#101652 Add config option to prevent disabling readonly mode It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Config option has been added. Search for "AllowEditReadonlyDocs" in expert config (Tools->Options->Advanced).
Just tested with the newest LibreOfficeDev 7.0.0 It worked flawlessly! The edit button is gone and not leading to problems anymore. Thank you for your effort! This helps us really a lot with our document handling. Might this fix be pushed to a version 6? regards BS Dev-Team
(In reply to BS Dev-Team from comment #17) > Just tested with the newest LibreOfficeDev 7.0.0 > > It worked flawlessly! > The edit button is gone and not leading to problems anymore. > > Thank you for your effort! This helps us really a lot with our document > handling. > > Might this fix be pushed to a version 6? > Sorry, only bugfixes go to version 6. This is rather a new feature. If you need this fix with an older version, you can contact one of the companies offering professional support who will gladly help you: https://www.libreoffice.org/get-help/professional-support/