Issue 73155 - Reconsideration of read-only mode
Summary: Reconsideration of read-only mode
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 2.1
Hardware: All All
: P3 Trivial with 20 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
: 75946 (view as issue list)
Depends on:
Reported: 2007-01-05 02:51 UTC by tora3
Modified: 2016-03-18 17:07 UTC (History)
11 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description tora3 2007-01-05 02:51:53 UTC
User scenario:

  1. A citizen visits a web site of public office to obtain an application form.
  2. She clicks on a link decorated with an icon of OpenDocument file format.
  3. The document is successfully opened in her web browser with, 
     but she cannot enter anything in it. 

   At this moment, many people simply close the document because it is not 
   editable, i.e. not usable for them. Consequently, they click on another link 
   decorated with an icon of Microsoft Office file format and achieve their
   Some people know that the document has been opened in a read-only mode and 
   it can be turned to be editable by clicking on an icon "Edit File" on the 
   tool bar of

  5. She clicks on the icon "Edit File" and gets an unwanted alert saying 
     "Object not accessible. The object cannot be accessed due to insufficient 
     user rights." accompanied with a white cross-shaped mark on a red circle.

   She becomes worried about violation of access right.

  6. She clicks on a button "OK" because there is no other choice.
  7. She gets another message saying "This document cannot be edited, possibly 
     due to missing access rights. Do you want to edit a copy of the document?"

   Now most people answer "No" although they know what they are doing, and they 
   abandon use of and go back to familiar office suite.

   She got warnings about insufficient access right two times. She did not want 
   to violate access right. She did not want to commit a crime. 

   A few, well-trained, experienced users know that the warnings 
   can be simply ignored. They answer "Yes" to the message to make a copy of the 
   document and start to edit it.

  8. She clicks on a button "Yes" to get a copy of the document and successfully 
     accomplishes filling a form.
  9. Now she notices that an original file name of the document has been lost 
     and is currently named "Untitled1."

   Being an experienced user, she easily succeeds in finding the original file 
   name by leaving her mouse pointer over the icon of OpenDocument file format 
   in the web page to get information on the link.

  10. She types the file name by hand to save the document and eventually 
      achieve her task.

What we could learn from the user scenario:

  What she might expect are: 
    1. She clicks on the link to open an application form.
    2. She wants to immediately start filling the document.
    3. She wants to save it with its original file name or similar name.

    a) She gets interrupted with unwanted warning messages two times.
    b) The messages are enough to make her worried about violation of access right.
    c) The original file name has been lost upon her saving the document.
Comment 1 Olaf Felka 2007-01-05 08:15:06 UTC
Comment 2 kpalagin 2007-04-05 10:38:25 UTC
*** Issue 75946 has been marked as a duplicate of this issue. ***
Comment 3 mtrausch 2007-04-06 20:46:51 UTC
I reported this bug to Ubuntu, and read the result of the discussion of Issue
75946.  Incidentally, that is where I learned about the Edit File button, which
is a nice feature.  If it could be put somewhere in the File menu—and work
“inline” without errors, that would be really nice, though.  I can imagine that
the errors before creating the new document would scare or deter some users.
Comment 4 Mathias_Bauer 2007-04-08 00:02:56 UTC
Yes, suppressing the error message would be a good step forward. 

Unfortunately this issue here is a little bit off-track in some other points.
The points 9 and 10 are wrong as the user won't be able to save to the original
location if step 5 resulted in an error message due to missing access rights. If
a saving to this location was possible this error message wouldn't appear.

And it mixes in another thing (the browser plugin) that is not related to the
read-only mode per se: whatever we might do to the "normal" mode we won't allow
for editing files in a browser window. This is not a safe environment as the
browser can kill the plugged window at any time without a chance to save the
content. Plugins shouls stay read-only all the time.

I will see if we can do something against the error message when a user clicks
on "Edit file" without having the necessary rights to access the file in writing
mode. Immediately asking for creation of a copy would be better, I think.

In a next step we can try to find out what might happen if we allowed write
access anyway as then the user will get the error message when she tries to save.
Comment 5 whistler 2009-09-02 06:21:08 UTC
Voted on this, because sometimes users may want to edit a file "on-the-fly" and
print it directly.

If editing is disabled in "read-only" mode, users would have save the file
first, edit & print the file and then delete the saved file, which adds extra
steps and is enough to affect the usability.
Comment 6 whistler 2009-09-02 06:31:11 UTC
well maybe I'm not experienced enough, but I didn't actually know about the
"Edit File" button until I read the bug#75946 as pointed by mtrausch today...

I think allowing users to edit the file when opening a read-only file is okay,
just give a warning message and popup the "Save As" dialog when user clicked
"save" is sufficient.
Comment 7 whistler 2009-10-22 05:30:18 UTC
it seems MS Word also just popup the "save as" dialog box when user clicked
"save" in read-only mode instead of disabling any editing, which definately made
it easier than OOo to just edit "on the fly" and print.
Comment 8 Brad Mace 2013-12-04 22:34:01 UTC
This is a major pain for us. In our case it's usually someone trying to view a generated spreadsheet on our intranet. Fill out a form, submit, and the browser prompts to open the spreadsheet.

The problem is that when you start looking around the spreadsheet you see some data that's cut off, so you go to resize the column, but you can't. You have to click the Edit File button (which I only learned of thanks to this bug report), then confirm another prompt, and then it becomes editable, but it also scrolls back to A1 so you lose your place.

There shouldn't be all these extra steps just to *view* information in a spreadsheet. With Excel you just open and adjust columns as needed, with no messing around.
Comment 9 Jason Spencer 2016-03-18 17:07:56 UTC
Issue 126877 makes this same request, which additional supporting arguments.