Bug Hunting Session
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: Not Assigned
URL:
Whiteboard: target:5.4.0
Keywords:
Depends on:
Blocks: Infobar-UX
  Show dependency treegraph
 
Reported: 2016-08-22 08:45 UTC by christian.rufener
Modified: 2017-03-29 09:37 UTC (History)
4 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.