Bug 47065 - Notification about document closure for locked readonly opened document
Summary: Notification about document closure for locked readonly opened document
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Master old -3.6
Hardware: Other All
: medium normal
Assignee: Matt K
URL:
Whiteboard: target:7.2.0
Keywords: difficultyInteresting, easyHack, skillCpp, topicUI
Depends on:
Blocks: Infobar File-Lock LibO-Enhancements
  Show dependency treegraph
 
Reported: 2012-03-07 09:54 UTC by Jan Holesovsky
Modified: 2021-11-21 01:06 UTC (History)
10 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 Jan Holesovsky 2012-03-07 09:54:44 UTC
This is an "Easy" Hack for somebody who likes more advanced hacking ;-)

When you open a document that is already open by a different user, you get a warning like "Document file '$(ARG1)' is locked for editing by:" (see STR_OPENLOCKED_MSG in uui/source/openlocked.src).  You have the choice to open it read-only, or a copy.  In case of opening it read-only, it would be great to get a notification when the document has been closed by the other person again.

The dialog is effectively created in sfx2/source/doc/docfile.cxx, SfxMedium::ShowLockedDocumentDialog().  In the case that it is opened read-only, you should trigger a thread that will wake up every minute, and check for the presence of the lock file.  If the lock file disappeared, it should create a notification dialog that the file is not in use any more; if possible, with an offer a reload of the file.
Comment 1 benoit.dolives 2012-11-18 10:29:40 UTC
This feature seems really interesting and I would like to give it a try as a first easy (but interesting) hack.

Let me know if you have some advices or objections,

Benoit
Comment 2 José Guilherme Vanz 2012-12-30 02:31:29 UTC
I start to try this bug. I debug the code to see where is more appropriated to start the thread. I think the SfxMedium::ShowLockedDocumentDialog is inappropriate place to do it. This function only show the user dialog and return the user choose, right?

The function SfxMedium::LockOrigFileOnDemand is appropriated?
Comment 3 José Guilherme Vanz 2013-01-07 14:15:57 UTC
The LibreOffice has some own thread API or can I use pthread.h API?
Comment 4 José Guilherme Vanz 2013-05-18 17:41:12 UTC Comment hidden (obsolete)
Comment 5 José Guilherme Vanz 2013-05-18 18:39:56 UTC Comment hidden (obsolete)
Comment 6 Björn Michaelsen 2013-10-04 18:46:11 UTC
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Comment 7 Björn Michaelsen 2015-02-10 09:07:01 UTC
ASSIGNED->NEW: No change since 2013 apparently ...
Comment 8 Robinson Tryon (qubit) 2015-12-14 05:00:15 UTC Comment hidden (obsolete)
Comment 9 Robinson Tryon (qubit) 2016-02-18 14:52:06 UTC Comment hidden (obsolete)
Comment 10 Matt K 2021-02-18 11:05:07 UTC
Assigning to myself.  Will also implement Windows specific behavior for detecting security permissions changes.
Comment 11 Commit Notification 2021-05-27 10:32:32 UTC
Matt K committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/95eb088802562b75f8b299908160145c7e88d763

tdf#47065 Add new file open UI options and implement a new thread

It will be available in 7.2.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 12 jcorrerocaballo 2021-08-04 16:47:25 UTC Comment hidden (off-topic)
Comment 13 Buovjaga 2021-08-04 19:14:55 UTC Comment hidden (off-topic)
Comment 14 bchemnet 2021-08-17 01:30:37 UTC
I encountered this dialog for the first time today after installing 7.2RC2.  Without commenting on the merits of the idea, I find the implementation problematic.  The problem is that every time I open an attachment from an email (something that happens several times a day), I now have a new dialog to click through before opening the file - and that extra click serves absolutely no purpose whatsoever, because I still have to active editing once the file opens (if I need it).

Is there a way to bypass or deactivate the new dialog for those of us who do not need this feature?  I never open a read-only file that is in use elsewhere - it is always read-only because of the storage location (using Linux), and I can easily activate editing and save elsewhere if I need to using the existing systems.
Comment 15 Heiko Tietze 2021-08-18 08:56:58 UTC
Matt, haven't seen the dialog (a bit confused by the fact that this ticket request information when the locked file becomes unlocked) but how about a "[ ] Don't show again" checkbox?
Comment 16 Kevin Suo 2021-10-21 09:36:57 UTC
(In reply to Heiko Tietze from comment #15)
See https://bugs.documentfoundation.org/show_bug.cgi?id=144650#c14
Comment 17 Kevin Suo 2021-10-21 09:56:57 UTC
I think this can be improved. If a file is initally read-only, it is not likely that it will be available for editing later. It is only possible to be edited only if it is "locked" at the time of openning.

I think initially read-only is different from been locked for a file?
Comment 18 Matt K 2021-11-13 20:07:39 UTC
I'm looking into addressing this in Bug 143971.
Comment 19 Matt K 2021-11-17 18:54:24 UTC
(In reply to Matt K from comment #18)
> I'm looking into addressing this in Bug 143971.

This is now fixed with https://git.libreoffice.org/core/+/f9ab31366dbe466ef739015734bb5b6a1a0deca4%5E%21
Comment 20 bchemnet 2021-11-21 01:06:50 UTC
Thank you.  I can confirm that the fix works for me in the latest daily build - no more dialog pop-up from a read-only location.