Download it now!
Bug 101652 - Allow to disable readonly infobar via configuration
Summary: Allow to disable readonly infobar via configuration
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Samuel Mehrbrodt (CIB)
URL:
Whiteboard: target:5.4.0 target:7.0.0
Keywords:
Depends on:
Blocks: Infobar-UX
  Show dependency treegraph
 
Reported: 2016-08-22 08:45 UTC by christian.rufener
Modified: 2020-04-21 14:23 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description christian.rufener 2016-08-22 08:45:32 UTC
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);
                 
}
Comment 1 Robert Großkopf 2016-11-27 15:18:07 UTC
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.
Comment 2 Gottfried Kunze 2016-11-28 13:59:56 UTC
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.
Comment 3 Luis 2017-02-23 11:17:58 UTC
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.
Comment 4 Samuel Mehrbrodt (CIB) 2017-02-23 13:02:14 UTC
(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.
Comment 5 Luis 2017-02-23 13:57:59 UTC
(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.
Comment 6 Commit Notification 2017-02-23 15:37:30 UTC
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.
Comment 7 Samuel Mehrbrodt (CIB) 2017-02-23 15:41:34 UTC
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?
Comment 8 christian.rufener 2017-02-23 15:52:23 UTC
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.
Comment 9 Luis 2017-02-24 12:35:31 UTC
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.
Comment 10 Robert Großkopf 2017-02-24 15:02:23 UTC
Could also confirm it solves the problem in Base-reports.

Well done, Samuel.
Comment 11 Timur 2017-03-28 17:01:50 UTC
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.
Comment 12 Samuel Mehrbrodt (CIB) 2017-03-29 09:37:22 UTC
(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.
Comment 13 Matthias Hellinghausen 2020-02-06 15:11:55 UTC
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?!
Comment 14 BS Dev-Team 2020-03-25 13:36:32 UTC
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
Comment 15 Commit Notification 2020-03-30 07:37:33 UTC
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.
Comment 16 Samuel Mehrbrodt (CIB) 2020-03-30 07:39:25 UTC
Config option has been added.
Search for "AllowEditReadonlyDocs" in expert config (Tools->Options->Advanced).
Comment 17 BS Dev-Team 2020-04-17 11:19:11 UTC
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
Comment 18 Samuel Mehrbrodt (CIB) 2020-04-21 14:23:53 UTC
(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/