When a Libreoffice document is open by a user A on a shared folder and user B tries to open it, he receives a warning that the file is in use. However, it also says something like "Alternatively, you can ignore the lock file and open the document anyway".
Which is what a non-technical user will choose without thinking, and should almost never do. At the very least, the warning should be far more strongly worded. Maybe "Alternatively, as a last resort, and if your system's management agrees, you can ...", and paint the button red, and insert a final "Are you really sure?" screen.
Better still, make read-only the only option, but I appreciate other users in other places might disagree (until they end up in a fight over whose hours of work have to be re-done).
It would also be helpful if all the information in the lockfile were relayed to the user attempting the second open. "$file is open for editing by $user on system $hostname and was opened at $time", because the correct work-around involves finding $user and asking him to save and close the file.
I've selected OS = Linux(All). I can't verify whether this behaviour also happens with Windows and Windows servers. Also can't say whether it's always been possible to override lockfiles, or not.
Steps to Reproduce:
1. User A on one system opens a file on a shared-for-write folder
2. User B on a second system attempts to open the same file
Mildly-worded warning screen that "invites" a non-technical user to commit a great mischief
Inability for non-technical user to open the file, or a strongly-worded warning screen that makes a non-technical user understand that ignoring a lock file is normally a REALLY BAD IDEA
User Profile Reset: No
This is an enhancement suggestion follow-up from bug 119381, which is fixed.
Build ID: 392729c735bb82eecf29bae5527ec786ca293f34
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Let UX have a look if wording can be improved.
Created attachment 149381 [details]
Maybe just show "Open read-only" and "Cancel" buttons by default.
Then have a checkbox "I want to override the lockfile" which changes the "Open read-only" button to an "Open" button.
Overriding the lock file should be done only when the previous process has not ended gracefully, right? Don't think we want to take over the work from other users- in this case we open readonly or as a copy.
Open readonly in local mode shows an infobar where the user can enable the edit mode. When opened as a copy (aka inserted from file) it shows the save dialog on ordinary save actions. Sounds like the usual way for me.
Rather than renaming a message that nobody care about we should tweak the workflow. The (technical) question remains how to deal with the lockfile from a terminated process. Can you evaluate this status safely anyway?
(In reply to Heiko Tietze from comment #5)
> Overriding the lock file should be done only when the previous process has
> not ended gracefully, right? Don't think we want to take over the work from
> other users- in this case we open readonly or as a copy.
No, please read comment 0, especially:
> When a Libreoffice document is open by a user A on a shared folder and user B tries to open it, he receives a warning that the file is in use. However, it also says something like "Alternatively, you can ignore the lock file and open the document anyway".
It can also happen that the lockfile from another user doesn't get cleaned up, so removing the option to open the file (despite locked by another user) is no option.
from the UX-meeting 2019-03-05:
Dialog + message needs to be discussed
+ "Opening editable potentially ends up in data loss when more users
access the same file."
+ checkbox "[ ] Open editable anyway"
+ buttons [Open] [Cancel] (no "Open read only")
(In reply to Cor Nouws from comment #8)
I don't think this is an improvement for the end user.
As there is the infobar when opening read-only, the user is informed. Is the current situation a problem, that is discussed in ask.libreoffice or elsewhere?
There is no infobar yet, but it would be consistent. If that's not possible without too much effort the proposal from comment 8 is fine.