topic Re: Using cmis, adding a new secondary type (aspect) removes association aspects, is this a bug? in Alfresco Archive

Using cmis, adding a new secondary type (aspect) removes association aspects, is this a bug?

ianw — Fri, 07 Oct 2016 16:00:27 GMT

The following groovy demonstrates the problem I'm having:import org.apache.chemistry.opencmis.commons.*import org.apache.chemistry.opencmis.commons.data.*import org.apache.chemistry.opencmis.commons.enums.*import org.apache.chemistry.opencmis.client.api.*def cmis = new scripts.CMIS(session)Folder fo

Re: Using cmis, adding a new secondary type (aspect) removes association aspects, is this a bug?

afaust — Fri, 07 Oct 2016 18:06:01 GMT

This is indeed the established behaviour that Alfresco has had the entire time I have been working with it (~6 years). Alfresco may automatically remove aspects when they define associations and/or properties of which none is currently being used on the node or the last of which has just been removed (e.g. if you delete the value of a property defined by an aspect and it was the last property of that aspect, it may be removed). Alfresco will not remove aspects that do not define any properties / associations at all (which can be used for semantic marking).

There are some variations on this behaviour depending on which API is used - I would assume the CMIS integration is built in a way that triggers this automatic removal.

Re: Using cmis, adding a new secondary type (aspect) removes association aspects, is this a bug?

kaynezhang — Sat, 08 Oct 2016 03:44:13 GMT

It seems alfresco will remove aspects that are already in item'existing aspects list but not in aspectsToAdd list in cmis implementation.

To avoid this problem ,you can get all existing aspects first and append them to the aspectsToAdd list.

Re: Using cmis, adding a new secondary type (aspect) removes association aspects, is this a bug?

afaust — Sat, 08 Oct 2016 08:05:45 GMT

In fact the "aspectsToAdd" is a detail of the CMIS client library and is not transmitted to Alfresco that way. The CMIS specification only provides an updateProperties operation where ALL secondaryTypes / aspects need to be included that should still be applied after the operation (current + new). In case the client library does not correctly merge the existing and aspects to add, Alfresco may remove those aspects that are not in the cmis:secondaryObjectTypeIds list. This is implemented in the CMISConnector.processSecondaryTypes operation.

I would check the HTTP request the client library sends to Alfresco if it contains all the aspects that were applied before PLUS the aspects you want to add.

Re: Using cmis, adding a new secondary type (aspect) removes association aspects, is this a bug?

kaynezhang — Sat, 08 Oct 2016 08:47:07 GMT

What I means is that alfresco server cmis implementation does not correctly merge the existing and aspects to add

It removes the aspects that are in existing aspects list but not contained in secondaryTypes in the parameter.

So to avoid the error deleting,in the client we can get all existing aspects first and append it to secondaryTypes List we are going to add.

Re: Using cmis, adding a new secondary type (aspect) removes association aspects, is this a bug?

afaust — Sat, 08 Oct 2016 08:50:44 GMT

As I said, merging existing and aspects to add is the responsiblity of the client library before sending the CMIS request. Alfresco is not allowed to override the request data from the client because that would effectively result in users not being able to remove aspects again...

Re: Using cmis, adding a new secondary type (aspect) removes association aspects, is this a bug?

kaynezhang — Sat, 08 Oct 2016 09:09:15 GMT

I got your point alfresco server should design that way .

Re: Using cmis, adding a new secondary type (aspect) removes association aspects, is this a bug?

ianw — Mon, 10 Oct 2016 13:12:26 GMT

I've checked the HTTP request and the existing aspects are indeed missing. I therefore conclude that there is a bug in the opencims client 1.0.0 for the function

CmisObject updateProperties(Map<String,?> properties,

List<String> addSecondaryTypeIds,

List<String> removeSecondaryTypeIds)

It seem sensible to use CmisObject updateProperties(Map<String,?> properties), however, when the aspect list is retrieved using getPropertyValue("cmis:secondaryObjectTypeIds") association type aspects are prefixed with "R:". If this is passed to updateProperties the opencmis library throws the error "Secondary types property contains a type that is not a secondary type: R:ncsrel:related". Changing the R: prefix to P: fixes the error, but feels wrong. Is this another problem with the opencmis client?

Re: Using cmis, adding a new secondary type (aspect) removes association aspects, is this a bug?

afaust — Mon, 10 Oct 2016 13:18:17 GMT

I fear the second part about the R: prefix might be a mapping bug inside of Alfresco. You have named the aspect and the association identically. I assume internally Alfresco is mapping Alfresco QNames to CMIS type IDs. The association ncsrel:related is mapped to the CMIS type ID R:ncsrel:related, overriding any prior mapping for the aspect. When Alfresco needs to map the aspect QName back to the CMIS secondary object type ID it picks up the relationship type ID instead.

Re: Using cmis, adding a new secondary type (aspect) removes association aspects, is this a bug?

ianw — Mon, 10 Oct 2016 14:30:58 GMT

Spot on, I've rename the association and all is working.

Thank you very much