[
https://issues.apache.org/jira/browse/CMIS-870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14225241#comment-14225241
]
Marco Biscaro commented on CMIS-870:
------------------------------------
Yes, Alfresco 5.0.b includes OpenCMIS 0.11.0. I've tested with 5.0.b and
verified the problem is fixed.
> Inconsistent cardinality - getProperties vs updateProperties
> ------------------------------------------------------------
>
> Key: CMIS-870
> URL: https://issues.apache.org/jira/browse/CMIS-870
> Project: Chemistry
> Issue Type: Bug
> Components: opencmis-commons
> Affects Versions: OpenCMIS 0.10.0
> Environment: Tested with Alfresco 5.0.a on Mac OS X using the browser
> binding.
> Reporter: Marco Biscaro
> Assignee: Florian Müller
> Priority: Minor
> Fix For: OpenCMIS 0.11.0
>
>
> I think the best way to explain this bug is through API response samples. For
> example, the following updateProperties call on Alfresco:
> {code}
> POST
> /alfresco/api/-default-/public/cmis/versions/1.1/browser/root?objectId=207ba708-714e-4740-96f8-5cfeabc9003f
> cmisaction=update&propertyId[0]=cm:title&propertyValue[0]=DocTitle
> {
> "properties": {
> (...)
> "cmis:secondaryObjectTypeIds": {
> "id": "cmis:secondaryObjectTypeIds",
> "localName": "secondaryObjectTypeIds",
> "displayName": "Secondary Object Type Ids",
> "queryName": "cmis:secondaryObjectTypeIds",
> "type": "id",
> "cardinality": "multi",
> "value": [
> "P:cm:titled",
> "P:cm:author",
> "P:sys:localized"
> ]
> },
> (...)
> "cm:title": {
> "id": "cm:title",
> "localName": "title",
> "displayName": "Título",
> "queryName": "cm:title",
> "type": "string",
> "cardinality": "single",
> "value": "DocTitle"
> },
> (...)
> }
> }
> {code}
> The response above is correct. The cm:title property (part of P:cm:titled
> aspect) has cardinality single and is returned as a string.
> The problem lies on the getProperties action. For example:
> {code}
> GET
> /alfresco/api/-default-/public/cmis/versions/1.1/browser/root?objectId=207ba708-714e-4740-96f8-5cfeabc9003f&cmisselector=properties
> {
> (...)
> "cm:title": {
> "id": "cm:title",
> "localName": "title",
> "displayName": "Título",
> "queryName": "cm:title",
> "type": "string",
> "value": [
> "DocTitle"
> ]
> },
> (...)
> }
> {code}
> As you can see, the cardinality is undefined and the value is returned as an
> array.
> Debugging the code, I realized that when the updateProperties endpoint is
> called, the method ServerTypeCacheImpl.getTypeDefinitionForObject is invoked
> and this method correctly registers all type definitions for secondary object
> types. This makes it possible to correctly determine the cardinality of the
> property when converting the response to JSON.
> However, when getProperties is called, the
> ServerTypeCacheImpl.getTypeDefinitionForObject method is *not* called, but
> the type definition is registered by invoking
> ServerTypeCacheImpl.getTypeDefinition, which does not register the secondary
> object types. When converting to JSON, the cardinality of the property is
> unknown and it is (incorrectly) returned as an array.
> I think the method getTypeDefinitionForObject should always be called, to
> correctly register secondary object types and ensure consistency between
> queries of the same object.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
