When using the CMIS atom endpoint in Alfresco for opening documents, Steps to reproduce: 1. Add an Alfresco CMIS server with the binding url: http://<host>/alfresco/cmisatom 2. Open an existing document or create a new one. 3. Save the document. 4. Selecting check out gives a hint in the titlebar of the window that something is wrong, it will say "1.0)workingcopylink" instaed of the actual filename. Pressing save will return an error: "Error saving the document ... Object not accessible. The object cannot be accessed due to insufficient user rights". Alfresco 4.1.3 is used and LibreOffice 4.0.0.3 on Windows and LibreOffice 4.0.1.2 on Ubuntu 12.10x64
Might be related to issue https://bugs.freedesktop.org/show_bug.cgi?id=56156
(In reply to comment #1) > Might be related to issue https://bugs.freedesktop.org/show_bug.cgi?id=56156 Not related to the above issue as this reproduces on 4.x. The above does not.
Same errors here: testing with LibreOffice 4.0.4.2 an ALFRESCO 4.2.c
Please don't change the version number as it indicates the oldest one where the bug can be reproduced.
This is my configuration: - LibreOffice 4.0.4.2 - Alfresco 4.2.c I tried to set up a new connection Name: Alfresco Type: CMIS from the menu ServerType: Alfresco 4 URL: http://servername:8080/alfresco/cmisws/RepositoryService?wsdl doesn't work URL: http://servername:8080/alfresco/cmisatom/RepositoryService?wsdl works an gives me "Main Repository" when pushing the search buttom Path: empty User: empty I had to put the credentials first So I can navigate to the site where I find my LibreOffice document that I uploaded through the browser before. I'm able to open it I get the message on top in LibreOffice "the document wasn't checked out". I edit the file and try to save it but the I become and "input output error". When I check the document out it was marked as checked out in the browser view and it changes the file name "filnename (Working Copy).ods". When I now try to save it I get an error "missing user rights on that file" and again "input outpu error". Kind regards INGO
Could it be a file locking problem? I use LibreOffice from a WinXP client
(In reply to comment #5) > This is my configuration: > - LibreOffice 4.0.4.2 > - Alfresco 4.2.c > > I tried to set up a new connection > Name: Alfresco > Type: CMIS from the menu > ServerType: Alfresco 4 > URL: http://servername:8080/alfresco/cmisws/RepositoryService?wsdl > doesn't work This is a known libcmis bug and fixed already. > URL: http://servername:8080/alfresco/cmisatom/RepositoryService?wsdl > works an gives me "Main Repository" when pushing the search buttom > Path: empty > User: empty I had to put the credentials first Alfresco has a special CMIS anonymous user, but libcmis can't autoguess that first as you need to be authenticated to get the Service document containing it. > So I can navigate to the site where I find my LibreOffice document that I > uploaded through the browser before. I'm able to open it I get the message > on top in LibreOffice "the document wasn't checked out". I edit the file and > try to save it but the I become and "input output error". > When I check the document out it was marked as checked out in the browser > view and it changes the file name "filnename (Working Copy).ods". When I now > try to save it I get an error "missing user rights on that file" and again > "input outpu error". What does the LibreOffice Window title give a title? As described by Marcus, in some cases (hard to define exactly when) LO doesn't update the opened document properly to the working copy.
Now I've tested it on Ubuntu 12.04 and LibreOffice 4.0.2.2 and everything seems to work: saving, locking, versioning and the URLs servername:8080/alfresco/cmisws and servername:8080/alfresco/cmisatom both work. >What does the LibreOffice Window title give a title? >As described by Marcus, in some cases (hard to define exactly when) >LO doesn't update the opened document properly to the working copy. I will try to describe what it does on WindowsXP...
It is possible from WindowsXP LibreOffice to open a file from Alfresco CMIS, but when I try to save the changes (without checking out the document) I get the "input output error". When "hcecking out" the document the title was not changed in LibreOffice but I can't check in a new version. When using LibreOffice with Ubuntu 12.04 all seems to work.
reproducible on Libreoffice 4.1.1RC1, Alfresco Community v4.2.0c, windows 7 64bit, going to test openSUSE and Debian clients on the weekend. Moreover if you open the (working copy) with libreoffice you can work normally. However, if you check the document back in, it still displays the (working copy)...and behaves very inconsistent from there on...I will describe better when I see a pattern. Would be really nice if this got fixed as we are planning a move to Alfresco in the next weeks.
Created attachment 90174 [details] not working cmis atom response (/alfresco/cmisatom endpoint)
Created attachment 90175 [details] working cmis atom response (/alfresco/service/cmis legacy endpoint)
Created attachment 90176 [details] traffic log of working legacy endpoint
Created attachment 90177 [details] traffic log of not working /alfresco/cmisatom endpoint
I've been investigating this some more. This might have something to do with libcmis and not libreoffice. I setup a proxy using charles through which I routed all libreoffice requests through to be able to see what was wrong. I was using Alfresco enterprise 4.2.0, but the same results can probably be reproduced in earlier versions. Using the old legacy endpoint /alfresco/service/cmis checking out will work using atom. This is because the returned cmis document on the checkout request is different to what is returned in the newer endpoints /alfresco/cmisatom (now also deprecated as of 4.2) and /alfresco/api/-default-/public/cmis/versions/1.0/atom. The newer endpoints also include information about relationships to other objects as specified in the cmis spec. Below is a snippet of the 5th request made on a checkout to the Alfresco server, the first one is on the working legacy endpoint, and the second is the failing newer endpoint. 1. http://localhost:8080/alfresco/service/cmis/s/workspace:SpacesStore/arg/p?path=%2FSites%2Flibreoffice-test%2FdocumentLibrary%2FTest%20document%20%28Working%20Copy%29.odt&filter=&includeAllowableActions=true&includePolicyIds=&includeRelationships=&includeACL=&renditionFilter= 2. http://localhost:8080/alfresco/cmisatom/be392f77-bc41-4794-9367-f5b1cf00984b/path?path=%2FSites%2Flibreoffice-test%2FdocumentLibrary%2F76%7Cworkspace%3A%2FSpacesStore%2F5d8908d9-1b4a-4265-b1de-5d7244fcea70%7Cworkspace%3A%2FSpacesStore%2F3885d9a2-0540-41ab-810a-38ccb1b160d6%7C%7Bhttp%3A%2Fwww.alfresco.org%2Fmodel%2Fcontent%2F1.0%7Dworkingcopylink&filter=&includeAllowableActions=true&includeACL=&includePolicyIds=&includeRelationships=&renditionFilter= What is different in these two is the path argument. Libcmis parses the file name (cmis:name property from the response atom xml) and appends it to the path to the document to open. In the legacy response there is only one cmis:name property available in the xml which is equal to the file name: <pre> <cmisra:object> <cmis:properties> ... <cmis:propertyString displayName="Name" propertyDefinitionId="cmis:name" queryName="cmis:name"> <cmis:value>Test document (Working Copy).odt</cmis:value> </cmis:propertyString> ... </cmis:properties> </cmisra:object> </pre> In the new endpoints there can be several occurances of this property in different parts of the response xml such as: <pre> <cmisra:object> <cmis:properties> ... <cmis:propertyString displayName="Name" propertyDefinitionId="cmis:name" queryName="cmis:name"> <cmis:value>Test document (Working Copy).odt</cmis:value> </cmis:propertyString> ... </cmis:properties> <cmis:relationship> <cmis:properties> <cmis:propertyString displayName="Name" localName="name" propertyDefinitionId="cmis:name" queryName="cmis:name"> <cmis:value>75|workspace://SpacesStore/3885d9a2-0540-41ab-810a-38ccb1b160d6|workspace://SpacesStore/5d8908d9-1b4a-4265-b1de-5d7244fcea70|{http://www.alfresco.org/model/content/1.0}original</cmis:value> </cmis:propertyString> ... <cmis:propertyString displayName="Name" localName="name" propertyDefinitionId="cmis:name" queryName="cmis:name"> <cmis:value>76|workspace://SpacesStore/5d8908d9-1b4a-4265-b1de-5d7244fcea70|workspace://SpacesStore/3885d9a2-0540-41ab-810a-38ccb1b160d6|{http://www.alfresco.org/model/content/1.0}workingcopylink</cmis:value> </cmis:propertyString> </cmis:properties> </cmis:relationship> </cmisra:object> </pre> From what I could find in the source code of libcmis in it seems that it does not select the correct occurance of the cmis:name property, it uses the last found in the document (which is the one found in the cmis:relationship) which is not correct. This is also why you will see 1.0}workingcopylink in the title bar in libreoffice when you check out a document. My C++ is a bit rusty, so I'm not sure that I'm able to fix this in an quick way, perhaps someone else could look at it? It would be pretty easy I guess to write a test case in the libcmis module which reproduce this error. I've attached logs of the requests made to Alfresco and the resulting atom response on the checkout action. I hope my investigation is useful!
Hello Marcus. Thanks for the investigations. I think you got the point here, but it won't be that easy to fix. There are several name properties here that need not to be messed up: * the one in cmis:properties is the one we really want. * the ones in the relationships need to be parsed with relationships (not yet implemented in libcmis) only. I did some more work on properties recently in libcmis master branch, but it would only enforce that problem as it is fetching all possible properties. We want aspect properties to be parsed if possible.
Cedric Bosdonnat committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e8df1838ec2d4aa52522334e94e77fae00223490 fdo#62531: checkout failed due to bad import of properties in libcmis The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Fixed in master. In the review queue for libreoffice-4-2.
I've successfully tested this against the master branch and it does work with all the alfresco atom endpoints. Tested checking in / out .odt documents and .docx documents. /alfresco/service/cmis (legacy) /alfresco/cmisatom (deprecated) /alfresco/api/-default-/public/cmis/versions/1.0/atom (current)
Cedric Bosdonnat committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4c9ed76114ace311737dcda487894514ee0991fa&h=libreoffice-4-2 fdo#62531: checkout failed due to bad import of properties in libcmis It will be available in LibreOffice 4.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.