[CMIS-870] Inconsistent cardinality - getProperties vs updateProperties

• Type: Bug
• Status: Resolved
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: OpenCMIS 0.10.0
• Fix Version/s: OpenCMIS 0.11.0
• Component/s: opencmis-commons

Environment

Tested with Alfresco 5.0.a on Mac OS X using the browser binding.

• Assignee: Florian Müller
• Reporter: Marco Biscaro
• Created: 19/Nov/14 22:55
• Updated: 25/Nov/14 21:34
• Resolved: 25/Nov/14 19:52

Description

I think the best way to explain this bug is through API response samples. For example, the following updateProperties call on Alfresco:

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"
    },
    (...)
  }
}

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:

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"
    ]
  },
  (...)
}

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.