When double-clicking on an office document in a currently mounted dav share in nautilus, openoffice.org displays a popup asking for identifier and password to access the share. However, only the password field is editable and the identifier can not be inputed. As a result access fails openoffice.org-writer-1:2.3.1-9.1.fc9.x86_64
Ideally I'd like to know the configuration of your webdav server to reproduce, I assume its apache ?
setting up my own little apache webdav server with password I get a user name and password dialog from OOo. There are later problems, but I seem to have that dialog functioning anyway.
fedora apache with mod_dav on https
davs:// then I guess. Hmm I don't get a problem with the identifier/username not being editable, but I do see that it's a total failure afterwards to actually *open* the document as the seeks and stuff are hopeless over dav/davs hidden behind gnome-vfs. If I extend the inbuilt OOo http/https neon stuff to also handle dav/davs then it works well for me, so I reckon I should do that anyway in the next spin. So... if you e.g. right click in nautilus and get the "Location" I assume it says e.g. davs://127.0.0.1/testme . If you then from the command line substitute https:// for davs:// and do e.g. oowriter https://127.0.0.1/testme/atest.odt does it give the authentication dialog, and in a usable form and then go on to successfully open the doc ?
(In reply to comment #4) > davs:// then I guess. > > Hmm I don't get a problem with the identifier/username not being editable, Actually after the fist failure in nautilus identifier/username gets non-editable, but you're right the initial dialog is ok > So... if you e.g. right click in nautilus and get the "Location" I assume it > says e.g. davs://127.0.0.1/testme . If you then from the command line substitute > https:// for davs:// The nautilus properties use davs and specity the port, but I didn't use this on the CLI > and do e.g. oowriter https://127.0.0.1/testme/atest.odt > does it give the authentication dialog, and in a usable form and then go on to > successfully open the doc ? It works if I do oowriter https://... with the URL cut & pasted from firefox (for bonus points I have a document with whitespace in its name, so you need to replace space with %20 and probably do the same for non-ascii characters)
2.3.1-9.7 *might* resolve these issues by routing the davs:// foo through the OOo webdav backend instead of the gnome-vfs one. Let me know if that has any effect, otherwise it might be something to do with the type of server authentication which I'd then have to try and reproduce here.
2.3.1-9.7 complains of an untrusted certificate issuer without showing any option to authorize the CA
Looking at gnome-vfs2 I see that it has a total copy of neon in there and one that doesn't support checking certificates at all apparently which is why e.g. gedit doesn't just say roughly the same thing on opening a .txt files on the same webdav export. Gods what a mess to have an embedded neon in gnome-vfs2, we should get rid of that. At least now we're now seeing the same thing, I just had neon hacked to ignore the cert problem on my quick and dirty setup. I can at least *match* the functionality of the gnome-vfs2 solution for now. With the forthcoming gvfs replacement for gnome-vfs2 I don't want to go too far down a complete implementation of all that stuff as it may become totally redundant if we get the reseat of OOo on top of gvfs.
1:2.3.1-9.8 solves the davs problem I must say it's a pleasure to report Fedora OpenOffice.org problems when they get fixed so fast. The package is not 100% clean however, and yum update fails Cleanup : openoffice.org-core ####################### [23/28] rm: ne peut enlever `/usr/lib64/openoffice.org/share/uno_packages/cache/registry': est un répertoire rm: ne peut enlever `/usr/lib64/openoffice.org/share/uno_packages/cache/uno_packages': est un répertoire Cleanup : openoffice.org-langpack-ru ####################### [24/28] error: %postun(openoffice.org-core-2.3.1-9.7.fc9.x86_64) scriptlet failed, exit status 1
Excellent, well not the silly typo in the post, but at least for getting access to the davs:// stuff
openoffice.org-2.3.0-6.10.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update openoffice.org'
openoffice.org-2.3.0-6.11.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update openoffice.org'
openoffice.org-2.3.0-6.11.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.