1) Create new Calc sheet as a non-administrator user of a macOS 10.15 system.
2) Enter some data.
3) Try to "Save As". The operation refuses to work. No Finder dialog is displayed.
4) The document title remains as Sans Nom 1 (Untitled 1) and can not be saved anywhere.
5) The beachball of death rotates for a while, then returns focus to the application.
For what it is worth, the ODS file contains column headers and data from a copy/paste operation from a database table.
Steps to Reproduce:
Saving a Calc file is impossible.
Be able to save a Calc file containing the copied data to a place of the user's choosing.
User Profile Reset: Yes
See also bug 126638
*** This bug has been marked as a duplicate of bug 126638 ***
Uncoupling this from bug 126638 as I believe I have found the cause of the behaviour I reported and it appears to be different to what the OP is reporting in that bug.
I have found that the problem in my case reported here in this bug report arises when there are parallel installations of LibreOffice, with names other than just "LibreOffice".
It appears that the notarization process must lock in the name of the app bundle somewhere in the system, and if that name is changed, for example, when a user installs an "evolution" version of LO in parallel to a "stable" version, then calling any Finder dialog is blocked by the OS.
I tried this with several different functions from within LO that are supposed to call a Finder dialog :
Adding a JAR archive under Preferences (for database driver configuration)
Each time, I get a beachball and no Finder dialog, effectively blocking the operation.
If I delete one of my parallel LO installations and rename the surviving one back to LibreOffice, everything seems to work as normal again.
Editing title to better reflect findings.
@Choph, this issue seems to be related to the notarization process
No doubt adding the application bundle to the list of "Full Disk Access" apps might solve this.
The installation should take of this, though, and it doesn't. Asking a user to specifically manually bypass the security model to allow whole disk access is bit of a problem.
I set to NEW
*** Bug 129133 has been marked as a duplicate of this bug. ***
(In reply to Alex Thurgood from comment #6)
> No doubt adding the application bundle to the list of "Full Disk Access"
> apps might solve this.
> The installation should take of this, though, and it doesn't. Asking a user
> to specifically manually bypass the security model to allow whole disk
> access is bit of a problem.
When LO is installed (in my case with Homebrew) "Save" and "Save as" dialogs run fine, but once the LO app is **changed** by running a language pack (installer), these (Finder) dialogs cannot be invoked any more.
By adding the (changed) LO app to the list of apps that are allowed "Full Disk Access", then the save dialogs can be invoked again.
In short: your suggestion is correct and relevant for the installation of language packs, because that installation should also refresh any relevant permission for the (changed) LO app.
The part "with parallel LO installations" could very well be dropped from the summary.
*** Bug 131017 has been marked as a duplicate of this bug. ***
*** Bug 130883 has been marked as a duplicate of this bug. ***
*** Bug 131666 has been marked as a duplicate of this bug. ***
*** Bug 128690 has been marked as a duplicate of this bug. ***
*** Bug 130209 has been marked as a duplicate of this bug. ***
So I installed Catalina on a fresh drive to investigate this issue.
As far as I can tell, this may be related to the code signing that is broken.
Granting "Full Disk Access" makes the issue go away
This may be hard to replicate, as now my copy of LO on a standard account is working without Full Disk Access. It may be because I manually verified using the command line to check the output from bug 126409, I don't know.
It's best done on a completely fresh install on a new Standard user to mimic what a new user would encounter
Build ID: 4e471d8c02c9c90f512f7f9ead8875b57fcb1ec3
CPU threads: 4; OS: Mac OS X 10.15.4; UI render: default; VCL: osx;
Locale: en-US (en_NO.UTF-8); UI-Language: en-US
Build ID: 6a03b2a54143a9bc0c6d4c7f1...
CPU threads: 8; OS: Mac OS X 10.15.4; UI render: GL; VCL: osx;
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
*** Bug 133044 has been marked as a duplicate of this bug. ***
*** Bug 131292 has been marked as a duplicate of this bug. ***
*** Bug 132025 has been marked as a duplicate of this bug. ***
As already suggested in duplicate Bug 132025:
codesign -vvv --deep --strict LibreOffice.app
automatically by the language pack installer would solve the problem?
*** Bug 134547 has been marked as a duplicate of this bug. ***
*** Bug 135353 has been marked as a duplicate of this bug. ***
*** Bug 134848 has been marked as a duplicate of this bug. ***