Bug 62845 - Option for "Document Viewer Mode" (read-only mode by default) required.
Summary: Option for "Document Viewer Mode" (read-only mode by default) required.
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Read-Only
  Show dependency treegraph
 
Reported: 2013-03-28 05:09 UTC by Jathan
Modified: 2020-02-24 12:01 UTC (History)
3 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 Jathan 2013-03-28 05:09:24 UTC
Problem description: 

I can not set LibreOffice in read-only mode by default in Writer, Impress or Calc, for work with these only as document viewers of .odf, .doc, .ppt and .xls files, for open any document without the need to save it in read-only mode previously manually in the save options in each file.

Steps to reproduce:

There are not steps to set LibreOffice in read-only mode by default.

Current behavior:

The same situation

Expected behavior:

That LibreOffice can be used in read-only mode by default as document viewer

              
Operating System: All
Version: 3.5.4 release
Comment 1 Rainer Bielefeld Retired 2013-03-28 06:00:41 UTC
That has been discussed at several places, some ideas to solve the problem can be found here (for WIN):
<http://forum.openoffice.org/en/forum/viewtopic.php?f=15&t=33742>

Currently there might be not many requests for this feature, but I can imagine applications where such a feature would be useful.

Example from my personal experience: Technical documentation for Building Automation in bigger objects (hospitals, administrative buildings...). This kind of systems never become ready, always smaller changes will be done, user finds out how to solve his problems, ... .  For these applications I contribute the technical documentation as a system of ODF documents on a net drive. They are all protected with "Open file read-only" to protect the documents from accidental changes. But if the user wants to leave a note, correct a mistake or whatever, he is allowed to do so without any urdles, only trusted persons have access to those net drives. So it might have some advantage simply to install their LibO with an option "always open in read only mode", they really normally only need a document viewer, only from time to time they edit documents.

There might be other applications where a PC (tablet, smartphone) normally only is used as a viewer, with feature to do edits if necessary.

So I think this is a legitimate feature request.
Comment 2 Robinson Tryon (qubit) 2013-04-08 18:34:57 UTC
Original conversation on Ask site:
http://ask.libreoffice.org/en/question/14477/put-libreoffice-as-unedited-document-viewer-only/
Comment 3 Terry Corbet 2015-02-13 06:52:33 UTC
The date on the original submission of this request and the comments at that time indicate that someone would give due consideration to the request. I can only guess from the absence of any action that no one, in fact, has really taken up this cause at LibreOffice.

Having spent several weeks trying to find a good solution to the requirement for a user to be able to easily navigate -- in both directions -- between the body text of a document and its associated endnotes, I think I can correctly state that, within the various toolkits supporting PDF, there is no good solution available.  If is frankly mind-boggling to go through more than a decade of postings and versions of Adobe software to see that they have completely failed to address this fundamental behavior in the reading of on-line text.

When the belatedly decided that documents were becoming interactive, they fell into the most fundamental Dykstra trap of 'far too early optimization' by concluding that they knew, better than any user or developer, that the only legitimate functionality concerning navigation would be as adjuncts either to data entry into forms or tracking the development cycle of authoring and publishing a document internally.  Annotations, consequently, are very, very ill-suited to providing the sort of user navigation experience that a reader of a document expects.

OK, I don't need to go on with a description of the inadequacy of the Adobe Reader [or any of its counterparts created by 3rd parties], the key point is that there is one tool which does provide a very decent, very robust ability for the reader to be re-directed in both directions to and from an endnote whilst reading the document.  It is the functionality of your swriter and that is why it is so terribly important that you give us an alternative to the workflow that just uses LibreOffice to product PDF documents to be read via their reader.  We need to be able to send .odt files to our readers and let them know how easy it is to open, read, and browse back and forth in an .odt document.  Please, please look at the very manageable engineering effort that would be required to deliver a version of the swriter configured as an sreader with almost all controls removed from the screen so that a reader, not a programmer, not a document editor, not a layout specialist, can read the beautiful content that your fine swriter product allows us to produce.
Comment 4 QA Administrators 2016-02-21 08:35:59 UTC Comment hidden (obsolete)
Comment 5 __noname__ 2017-06-30 14:22:48 UTC
This bug is still present in LO 5.2.7.
Comment 6 QA Administrators 2018-07-02 02:36:07 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug