See https://issues.apache.org/ooo/show_bug.cgi?id=117598
(In reply to comment #0) > See https://issues.apache.org/ooo/show_bug.cgi?id=117598 I assume you refer to <https://issues.apache.org/ooo/show_bug.cgi?id=117598#c3>, trying to save a modified ("physically") read-only document gives an error instead of automatically behaving as "Save As..."?
Indeed. Sorry for the terseness, here is the said comment: 1. make an OO-document (doesn’t matter which type, can be .doc also) read-only 2. open it (with OO of course); it is opened in read-only mode. 3. click ‘edit’ button (5th from left) 4. edit the document 5. save (Ctrl-s) 6. get error message: Fout bij opslaan van document XXX: Geen toegang tot object. U hebt geen toegangsrecht tot object. (English: error saving, no access. You have no right of access) Expected behavior: Ctrl-s behaves like Ctrl-Shift-s (save as) and the name of the current file is suggested as name, or maybe ‘copy of …’ Versie: 4.1.4.2 Build ID: 410m0(Build:2)
This seems to be another secondary issue of the commit which caused bug 65498. I'm leaving this as a separate bug so it gets tested separately when that issue is fixed. [This wasn't an OOo bug to begin with, the linked bug has been closed with ~"This is an LO bug, not an OOo bug"] Not adding Cc: to sbergman@redhat.com because I see you're already there ;) ; Could you possibly take a look at this one too? Thanks (see bug 65498 comment 4)
I cannot reproduce this, neither with a local 4.1 build nor with local 5.0 master builds (with and without the fix for bug 65498) (all on Linux). When opening a document (from the local filesystem) that is read-only at the filesystem level, "Save" is disabled and remains disabled also after switching to "Edit Mode"---only "Save as" is available. Hendrik, are you still able to reproduce this problem with recent LO versions (if yes, on which OS)? (And sorry for the long delay.) Matthew, have you acutally been able to reproduce this problem?
@Stephan - I can reproduce this on 4.4.2.2. For some reason the accelerator and the save icon become unsynced, because after making some change to the read-only file Ctrl+S works (but fails with the "can't write" dialog), while as you point out the save icon remains disabled - this seems like a bug, though not the one originally reported ;) Perhaps this report is more of an enhancement request though, the behaviour before wasn't exactly what is suggested in comment 2. Before 3.6, the behaviour when the underlying file was read-only was to refuse to edit the file under its original name, and insist on forking to a new Untitled file when the edit button was pressed (a dialog offers you a choice of Yes -> Untitled file, or No -> don't edit after all). Thus, saving after starting to edit would always behave as Save As. Since 3.6, the edit button / infobar (since it was introduced) unconditionally allow editing while leaving the file under its original name - so saving after starting to edit will fail. I don't think returning to the earlier behaviour would be ideal, because for one thing that would mean that the path of the edited file would not be available from the titlebar in OSX (a useful feature which allows you to jump to the folder of the file). However, the current behaviour is also rather unfriendly. Perhaps something like a dialog which warns the file is read-only, and offers "Save As" or "Cancel" ?
(Tangential issue with the save icon split into bug 90891) Improving this will require changing the UI behaviour, so let's send this over to ux-advise for an opinion on the best way to deal with it. UX team - could you take a look at this one? Thanks
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
Adding Cc: to Stephan Bergmann
Initially fixed for 5.1 by setting the FastCall sdi flag of SID_SAVEDOC to false in https://cgit.freedesktop.org/libreoffice/core/commit/?id=22328a224df4619218b88205838307f70612207e With current master and 5.3, both the save button and Ctrl-S are enabled, and will lead to save as (see Bug 104106).
(In reply to Maxim Monastirsky from comment #10) > Initially fixed for 5.1 by setting the FastCall sdi flag of SID_SAVEDOC to > false in > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=22328a224df4619218b88205838307f70612207e > > With current master and 5.3, both the save button and Ctrl-S are enabled, > and will lead to save as (see Bug 104106). Great, thanks!