I confirm the problem in 7.3

Ok Mike, if you think it's a bug, then I bisected it and it was your own commit
 95eb088802562b75f8b299908160145c7e88d763

https://gerrit.libreoffice.org/c/core/+/111654

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

(In reply to Roman Kuznetsov from comment #1)
> it was your own commit

Please be precise in what you state ;) it was not "my" commit, but only what I merged, as already stated at the Ask question:

> I myself helped that change by reviewing and approving it.

The author of the commit is Matt K.

*** Bug 144659 has been marked as a duplicate of this bug. ***

confirmed under kubuntu 18.04

*** Bug 144845 has been marked as a duplicate of this bug. ***

(In reply to Roman Kuznetsov from comment #5)
> *** Bug 144845 has been marked as a duplicate of this bug. ***

In a Bug 144845 I offer change upper information string that appears if we open a read-only document. Button "Notify" could be move from popup to this string.

Created attachment 175496 [details]
Mock-up of comment #6 suggestion

@comment #6
That seams as a good suggestion. It would not complicate code further, it would simplify it. Mock-up attached.

(In reply to Mikeyy - L10n HR from comment #7)

IMO moving this to an infobar is unrelated to the problem here (I don't have any personal preference on dialog-vs-infobar approach myself FWIW).

There should be *no* potentially confusing, unneeded information for user whenever the program *is able* to figure that the information is unneeded/wrong, even if that means that we need a more complex code.

In case when application can detect that the file will never get "unblocked", like when we are opening a file from a known-temporary location, the suggestion to notify when available should *not* appear. Anything else is just trying to make application's fault less intrusive.

(In reply to Mike Kaganski from comment #8)
> In case when application can detect that the file will never get
> "unblocked", like when we are opening a file from a known-temporary
> location, the suggestion to notify when available should *not* appear.
> Anything else is just trying to make application's fault less intrusive.

+1 to this and +1 to the request. The interrupting dialog is not necessary since we have the infobar.

*** Bug 144936 has been marked as a duplicate of this bug. ***

*** Bug 145541 has been marked as a duplicate of this bug. ***

I just upgraded to 7.2.2.2 and immediately got hit with this bug (new feature?) and find it interesting that all reports and duplicates about this issue so far have been in regard to Thunderbird or Firefox.  My situation is even more straight forward, I think.

I have a number of shared templates which I keep on all my systems in:

    /usr/local/share/libreoffice/


I only find a need to edit or update these files on rare occasion and their ownership belongs to root, making them, by definition 'read-only' for a normal user.

So now, *every time* I start Writer I'm presented with a blank grey screen and the pop-up saying "Document file 'outline.ott' is read-only."  I then choose the "Open Read-Only" button, and after a ridiculously long (5 to 15 second) delay I get a new, editable "Untitled 1" copy as I normally would have *without any wait* in previous versions.

Since every part of my workflow involves calling up a new instance of one or more of these shared templates you can understand that I am seeing this pop-up box *a lot*.

Also, if (on Writer invocation) I choose the "Cancel" button instead, LibreOffice immediately exits me back to my desktop.

I'm guessing this isn't the intended user experience?

Oh, I guess I should have added that I'm confirming this issue both for Mageia 8 (version 7.2.2.2 from the repos) as well as TDF Fresh which I downloaded to compare against.

And again, it surprises me that the reports so far have been mostly for Thunderbird attachments, because all users (or just Linux ones?) opening any *builtin* template(s) should being seeing this pop-up bug just as constantly as I am; both on Writer invocation (with the default builtin template) and every time they open another one via the Template Browser.

And the delay I'm seeing?  I'm guessing that's because LO has to first figure out it's a template file and then spawn an *editable* copy instead?

Can we please revert this "functionality" and leave it as it was since it slowing down and making it harder to work with LO. If you want to change it later, take as much time as you need, but bring back old behaviour first.

Okay, after some further review, my claims of long delays were exaggerated.  Once LO has fully initialized any additional templates opened via the Template Browser spawn their editable copies fairly quickly.

Still, that pop-up is as annoying as... annoying can be, and I'm with Mikeyy on this: can this "functionality" please be removed until a more robust solution for collaborative notification can be found?

Thinking further about the actual underlying issue, it appears to me (from my armchair, non-developer point-of-view) as though LO's test that triggers the pop-up in the first place is too vague: as if it's doing nothing more than a simple boolean check on the write permissions of the document being opened.

Wouldn't it be better if LO first tested the document's write permissions, and *then* spring the pop-up *only* if it (the document) is both writable and *already* open for editing somewhere in the collaborative ecosystem?  There's absolutely no point in testing the open/closed status of strictly READ-ONLY documents because they should be viewable by any number of users simultaneously anyway.

Does this make sense, or am I completely misunderstanding the problem?

I'm here? i'm vote YA for removing this stupid annoying dialogue. All LO have ruined. What 'genius' thought that? One that never working in LO with documents!
Designer that added this dialogue - if you does not implement changes in mock-up attached - delete, remove your dialogue.

We already have over 10 CCed people, I increased the Importance

I think the behavior observed was in attempts to match Microsoft Office's similar feature, though I don't have Office installed to test at the moment.

I'll look into switching to an InfoBar notice/button, though it will likely be an additional bar which will clutter the screen further.

Some things to clarify are:  Should the new button feature be opt-in or opt-out?
Do we still want a button for the user to remember their preference?

What is "opt-in" / "opt-out"? Sorry my incompetency, but I dont know. I think make that viewed in mock-up. Just additional button.

(In reply to Matt K from comment #18)
> I think the behavior observed was in attempts to match Microsoft Office's
> similar feature, though I don't have Office installed to test at the moment.

I don't think so. Please look at the description carefully.

> I'll look into switching to an InfoBar notice/button, though it will likely
> be an additional bar which will clutter the screen further.

Unfortunately, it seems that comment 7 confused it all a lot. It has suggested that infobar "solution", and it was absolutely unrelated to the problem here, which is *showing your new *generally useful* information in situations which are *known* to not need it*.

Again: the only solution to *this* bug is to make sure that the dialog (or infobar, or whatever other means to display the suggestion to inform about document availability) is *not* offered to user for files opened from temporary locations. This requires the place where the dialog is invoked to know what was the reason that made the document read-only; this information is likely needed to be propagated there from the place where the decision is made.

> Some things to clarify are:  Should the new button feature be opt-in or
> opt-out?
> Do we still want a button for the user to remember their preference?

Note that I do not object to the infobar idea itself; but *only* as a separate enhancement, like "move the "notify me" button from dialog to infobar", completely independent from this one.

(In reply to Mike Kaganski from comment #20)
> Unfortunately, it seems that comment 7 confused it all a lot

And comment 6.

Comment 6 just offered one way of solving this. With that solution you could still keep "Notify" option while not blocking file opening with additional popup. It's a user suggestion.

Comment 8 offered another one. But as you can see in comment 12, hardcoding known read only places could be tricky.

(In reply to Mikeyy - L10n HR from comment #22)
> Comment 8 offered another one. But as you can see in comment 12, hardcoding
> known read only places could be tricky.

No, the idea is not to hardcode something, but to provide an (extensible) mechanism to know at the site where the information needed, why the document is read-only. Then it may make an informed decision. And we may decide based on "it was in a known-temp directory"; "it is on a RO filesystem"; "it has RO permissions for this user"; "it has a lockfile"; "there is filesystem-level sharing conflict"...

Note also that this problem in fact was anticipated back then in https://gerrit.libreoffice.org/c/core/+/111654/44#message-acfa1b909c92b86c166933a9ab5856da1e01548c - the idea was suggested then that we disambiguate "file is locked" vs "no write permissions". It was rejected then, but I still believe that this is what *must* be done here.

(In reply to Mike Kaganski from comment #20)
> > I'll look into switching to an InfoBar notice/button, though it will likely
> > be an additional bar which will clutter the screen further.
> 
> Unfortunately, it seems that comment 7 confused it all a lot. It has
> suggested that infobar "solution", and it was absolutely unrelated to the
> problem here, which is *showing your new *generally useful* information in
> situations which are *known* to not need it*.

I disagree that there are some situations that don't need it. Some users may want every read-only location monitored in case some script or administrator makes a file available.  How would you distinguish cases like these from being "need" or "not need"?
 
> > Some things to clarify are:  Should the new button feature be opt-in or
> > opt-out?
> > Do we still want a button for the user to remember their preference?
> 
> Note that I do not object to the infobar idea itself; but *only* as a
> separate enhancement, like "move the "notify me" button from dialog to
> infobar", completely independent from this one.

So is the work for this bug simply to choose which directories to exclude, and if so how does that apply to the ambiguous cases above?


(In reply to Mike Kaganski from comment #24)
> Note also that this problem in fact was anticipated back then in
> https://gerrit.libreoffice.org/c/core/+/111654/44#message-
> acfa1b909c92b86c166933a9ab5856da1e01548c - the idea was suggested then that
> we disambiguate "file is locked" vs "no write permissions". It was rejected
> then, but I still believe that this is what *must* be done here.

What if the user wants "special" cases to be monitored rather than not?  We could just give the user an opt-out to let the user decide.

(In reply to Matt K from comment #25)

Your comment basically repeats what you answered there in the change. Let me quote it:

> Why not check if it's the current state of things?  I just tested MS Excel and
> they also check permissions before notifying the user, so MS must think there's
> some scenario.
> 
> Real-life scenario: User protects their documents folder because they want to
> protect against a rogue script in an open source project from "rm -rf" all of
> their documents.  Later they decide they trust the the project and remove the
> protections, then their open documents ask them to Reload.  Another scenario
> might be if there's a sysadmin managing ACLs, and the user with open documents
> doesn't know the sysadmin changed things.

I really regret not checking that MS Office offers to notify when the file becomes available; I did it now, using MS Office 2016.

So *both MS Word, and MS Excel*, when opening a file that is locked by another process, but otherwise has write permissions, offers to notify when it becomes available. But when opening a file with Read-Only attribute set, or a file with write permission denied ACL, it *does not* offer the dialog with options, and simply opens the file in read-only mode (indicated in the app title, and of course with disabled controls).

So no, there is *no* realistic scenario that would require us to monitor filesystem changes other than locking - all other imaginable changes, like removed Read-Only attributes or filesystem permissions are *not* in the scope of original enhancement, and are reasonable to require user to reopen manually. The problems are real, and the scenario which would benefit is one per 1000 000 000.

@Mike Kaganski: Thank you!

As far as I can see, everything you say in Comment 26 appears to coincide with how I imagined this "feature" *should* work in the second last paragraph of Comment 15.  Specifically:

"There's absolutely no point in testing the open/closed (i.e. locked) status of strictly READ-ONLY documents because they should be viewable by any number of users simultaneously anyway."

Still, I feel a bit concerned about the continued emphasis on "files in *temporary* locations".  My templates are *not* stored in locations that are in any way *temporary* (/opt/libreoffice7.2/ ; /usr/share/libreoffice/ ; /usr/local/share/libreoffice/).  Though always READ-ONLY, they'll *never* be locked, so should fall under the above criteria.

I'm really looking forward to this issue getting fixed, because frankly gentlemen, as it stands, that little dialogue is driving me batsh*t! :(

@Mike Kaganski: Never mind.  I reread some of what you'd said earlier more carefully and had a look at your gerrit comment, so I think you've already -- at least in theory -- addressed my remaining concerns.  Thanks.

(In reply to Matt K from comment #25)
> I disagree that there are some situations that don't need it. Some users may
> want every read-only location monitored in case some script or administrator
> makes a file available.  How would you distinguish cases like these from
> being "need" or "not need"?
>  
> ...
> 
> So is the work for this bug simply to choose which directories to exclude,
> and if so how does that apply to the ambiguous cases above?
> 
> ...
> 
> What if the user wants "special" cases to be monitored rather than not?  We
> could just give the user an opt-out to let the user decide.

Okay, again, here's my knee-jerk, non-developer take on everything you've said above, so please cut me some slack if it's completely crazy.  All your efforts (and concerns) are rooted in using LO in a collaborative multi-user environment, right?

So how about, instead of approaching your *second* concern with a directory *exclusion* paradigm, you come at it from the opposite direction of *inclusion*?  By default, let a vanilla install of LO monitor *nothing* for file statuses to notify about.

Then to establish *inclusion*, let your *first* and *third* concerns be addressed via a new settings panel in the Internet subcategory of the Options window.  Perhaps it could be called "Collaborative Networking" or something.

Your *first* concern, with regard to an administrator or script making a (formerly) READ-ONLY file available, sounds to me like you're assuming the file is located on some remote network drive or share.  So let's put a checkbox on our new hypothetical panel to "Monitor Remote File Shares".  With this checkbox activated, LO would periodically poll for file permissions changes on any NFS, Samba, or whatever-other-protocol shares accessible to the users' filesystem(s).  Maybe the polling period could even made customizable (every 5, 10, 15 minutes, etc.).

Then, about your *third* concern for users' "special" cases: don't make them *opt out*!  To me, that's completely counterintuitive.  Instead, have them *opt in* because they know there's actually *something there* to opt-in to, and because they actually *want* to do so.  My suggestion?  On our new hypothetical panel, below the "Monitor..." checkbox, have a path-list box where users (or in an enterprise environment, the IT staff) can add specific locations that need to be monitored.   Perhaps for especially esoteric use cases this path-list box could also provide even more-granular options to apply on a path-by-path basis.

Just to reinforce my opinion:  taking the position of opting *everything* IN by default, and then forcing the *user* to opt out, seems like a terrible idea to me, because *OPENING LIBREOFFICE UP TO THE WORLD* this way would likely expose countless new security vulnerabilities.  By default, I think it would be better to keep the castle gates locked and the drawbridge up, if you know what I mean -- the same way you would with a firewall.

So there you go.  I'll conclude by underscoring my disclaimer that, as a non-developer, I have no clue whatsoever if LO is (currently) capable of anything I've suggested here (especially in the monitoring of network protocols), nor how difficult any of this would be to implement, nor how ponderous it would be for enterprise IT departments to deploy custom paths; but I hope some of my fanciful thoughts regarding this issue were, at the very least, a little constructive or inspiring. :)


P.S.  I should maybe add that I haven't used Windows in nearly 20 years, and the last component of MS Office I've ever touched was Word 97, so feature wise, I have absolutely *nothing* proprietary on hand to compare to. ;)

Note that bug 47065, that introduced the dialog, is titled "Notification about document closure for *locked* readonly opened document". The description of it focuses on the specific situation "when you open a document that is already open by a different user". Nowhere there was it imagined that there will be this expansion of the functionality to the made-up situation of *administrator* making changes to file permissions, where user needs to learn about that from the software.

File locking when several users access a document is familiar workflow, allowing only one person to edit it to disallow the file breakage, and it indeed is nice when you can have better coverage of the release of the document. It is not reasonable that one user who opened a document would then notify other unknown users when the document is closed.

Administrative tasks are specific. Administrator does their job to *address something* for their users; their results *must* be communicated to the users somehow. These tasks are not nearly as frequent as simultaneous opening by several users. So again: no, we do *not* need to implement this imagined "admin is in process of unlocking, and I expect LO to tell me that" scenario. There should be *no* new options to address this. The functionality should be tuned to address specific task in the original bug, and avoid the non-spercific bits introduced just "because we can".

Okay, 10-4.  As you said in Comment 26, it's "*not* in the scope of original enhancement".  Sorry about the mess.  I won't concern myself with this business any further except to say goodbye and good riddance to that dialogue once this gets resolved.  Thanks again.

(In reply to Mike Kaganski from comment #26)
> 
> So *both MS Word, and MS Excel*, when opening a file that is locked by
> another process, but otherwise has write permissions, offers to notify when
> it becomes available. But when opening a file with Read-Only attribute set,
> or a file with write permission denied ACL, it *does not* offer the dialog
> with options, and simply opens the file in read-only mode (indicated in the
> app title, and of course with disabled controls).
> 

Have nothing to add here. Seams like an elegant solution which will cover 99% of use cases.

Fix tracked in https://gerrit.libreoffice.org/c/core/+/125340

Matt K committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f9ab31366dbe466ef739015734bb5b6a1a0deca4

tdf#143971 Removes pop-up dialog for read-only documents

It will be available in 7.3.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.

Matt K committed a patch related to this issue.
It has been pushed to "libreoffice-7-2":

https://git.libreoffice.org/core/commit/63cb67f9e7a1920b43510df8f222c88a56fdf82d

tdf#143971 Removes pop-up dialog for read-only documents

It will be available in 7.2.4.

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.

Jumping over from the related 47065: the fix works exactly as intended for me with the latest daily build.  I do not get a dialog popup when opening from a read-only location.  Thank you.

*** Bug 145981 has been marked as a duplicate of this bug. ***

Downloaded LO 7.2.4.1 (RC1) today from https://dev-builds.libreoffice.org/pre-releases/win/x86_64/

Version: 7.2.4.1 (x64) / LibreOffice Community
Build ID: 27d75539669ac387bb498e35313b970b7fe9c4f9
CPU threads: 12; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: hr-HR (hr_HR); UI: hr-HR
Calc: CL

New popup is still showing. Fix didn't work.

Thunderbird saves xlsx file in: C:\Users\Username\AppData\Local\Temp
When I go to that folder, right click file and slect "Properties" it shows "checkmark" on "read-only" atribute.

7.2.4 was a hotfix release, updating target in status-whiteboard

Could this fix have caused a regression in 7.2.5?
Opening Thunderbird attachments are now no longer read-only files, but saved automatically in the Temp-Folder of Windows.

(In reply to amersdorfer from comment #40)
> Could this fix have caused a regression in 7.2.5?
> Opening Thunderbird attachments are now no longer read-only files, but saved
> automatically in the Temp-Folder of Windows.

Doubt it. I also noticed same thing, but it start happeing after TB 91.4 or 91.4.1.

> Doubt it. I also noticed same thing, but it start happeing after TB 91.4 or
> 91.4.1.

No, there was no change in behaviour with 91.4.x and it would make no sense - once you open the attachment, Windows takes over and TB loses control over the file.
This behaviour definitely changed with 7.2.5.

Same behaviour continues if you uninstall LO 7.2.5, delete user profile, and then install LO 7.2.4.1.
It's not LO issue.

(In reply to Mikeyy - L10n HR from comment #43)
> Same behaviour continues if you uninstall LO 7.2.5, delete user profile, and
> then install LO 7.2.4.1.

I completely agree that this is not a regression, and definitely not related to this fix.

> It's not LO issue.

Still, this is an LO issue - we should detect that the file is in temp directory, and mark it RO, as we did for the previous location. This needs a separate bug report.

> Still, this is an LO issue - we should detect that the file is in temp
> directory, and mark it RO, as we did for the previous location. This needs a
> separate bug report.

OK, I reported a bug under https://bugs.documentfoundation.org/show_bug.cgi?id=146642

I can confirm that this issue is still present in LO 7.2.4 (Manjaro & Ubuntu).
It's not only happening when you open a file from Thunderbird or Firefox, but also when you want to create a new document from a stock template (as said in comment 12).
Since this dialog is a separate (small) window, one can easily overlook it in the background and think the file simply didn't open.
This dialog should appear when a file is LOCKED because another user is working on it. It doesn't make sense if it shows when the file is marked as read only by the OS: in this case, the "old" info bar saying the file is open as read only was a very good solution.

(In reply to Frédéric Le Cam from comment #46)
> I can confirm that this issue is still present in LO 7.2.4 (Manjaro &
> Ubuntu).
Please note the target version on the whiteboard (7.2.5), and comment 39.

Thank all who makes this dialog disappeared.

Here is my environment and condition:
OS: Mint 20.04
LibreOffice: 7.2.5

I have many computers. In one computer I access files locally and in others I access files remotely via samba.
When read-only file is local, it is opened into read-only mode directly now.
When read-only file is remote, the dialog is still there.

> the "old" info bar saying the file is open as read only was a very good solution.

I aggree.

The dialog said:

1. Open Read-Only
   This should be default option.
2. Notify
   This option should work in the background. Ask me ONLY if any status changed. 
   In my case, no one changes my files.
3. Open Copy
   I believe that file can be loaded into memory first (The "Open Read-Only" first), and then "Open Copy" if necessary. No matter (1) reload the file, or just (2) change the status with title to be "Untitled 1", location to be "None", or something else...
4. Cancal
   Not necessary option.
   If necessary, the actions should be manually (open it and then close it manually).
   If still necessary before open file, it should be
   "No permission, please leave"
   "Cannot open file with blah blah reason, please leave"
   The current "Read-Only" is not a necessary reason to "Cancel".

(In reply to icheng.shen from comment #48)
> When read-only file is local, it is opened into read-only mode directly now.
> When read-only file is remote, the dialog is still there.

This would be a bug, but please file it separately, with clear steps to reproduce (including the steps to configure the remote share). This bug is resolved, and we need to limit one bug to a single issue, even if other issues are similar or related.

> 4. Cancal
>    Not necessary option.
>    If necessary, the actions should be manually (open it and then close it
> manually).

Whenever there can be a button on otherwise empty space, that saves some clicking, it is better than "simplifications" like "click another button, then find another close button in another part of the UI". No one uses keyboard accelerators, and people really care about extra clicks they need to do. Unless you really *resolve* something, the urge to simplify things often makes others unhappy.

(In reply to Mike Kaganski from comment #49)
> No one uses keyboard accelerators

Sorry, I meant "not everyone uses keyboard accelerators"