Hello everyone,
I wanted to know how to define a property in a custom model in order to set its updatability to "oncreate". If I use the "protected" tag, it will set the updatability to "readonly", and this is not the behaviour I am looking for.
Thanks in advance!
All properties (even protected ones) can always be modified. In the core there is technically nothing to limit the property editability to either "oncreate" or "readonly". Only some APIs, e.g. CMIS, may have some special mapping that supports "readonly" - unfortunately you did not specify what kind of APIs you are using where you saw that "readonly".
But long story short: There is no such thin as "oncreate" updatability in Alfresco, and even "readonly" is just a fancy result of API mapping, but not really a thing in the core of Alfresco.
My apologies for not being specific enough.
We are using Apache OpenCmis 1.1.0, and we connect to Alfresco using AtomPub.
At some point in the initial loading of our software, OpenCmis queries Alfresco using an AtomPub call and gets an XML description of the model. In that XML structure, our custom property is described like this (now it shows as "readwrite" because we removed the "protected = true" definition from the model):
<cmis:propertyStringDefinition>
<cmis:id>gem:internalcode</cmis:id>
<cmis:localName>internalcode</cmis:localName>
<cmis:localNamespace>http://www.geminys.com/model/geminys/1.0</cmis:localNamespace>
<cmis:displayName>gem:internalcode</cmis:displayName>
<cmis:queryName>gem:internalcode</cmis:queryName>
<cmis:description>gem:internalcode</cmis:description>
<cmis:propertyType>string</cmis:propertyType>
<cmis:cardinality>single</cmis:cardinality>
<cmis:updatability>readwrite</cmis:updatability>
<cmis:inherited>false</cmis:inherited>
<cmis:required>true</cmis:required>
<cmis:queryable>true</cmis:queryable>
<cmis:orderable>true</cmis:orderable>
<cmis:defaultValue/>
</cmis:propertyStringDefinition>
This is the "updatability" trait I was referring to. Since it came from a call to Alfresco via the AtomPub api, my understading was that it was Alfresco who provided it, not OpenCmis.
Our goal was to reproduce the behavior of the property cmisbjectTypeId, whose definition via the same request is:
<cmis:propertyIdDefinition>
<cmis:id>cmis:objectTypeId</cmis:id>
<cmis:localName>objectTypeId</cmis:localName>
<cmis:localNamespace>http://www.alfresco.org/model/cmis/1.0/cs01</cmis:localNamespace>
<cmis:displayName>Object Type Id</cmis:displayName>
<cmis:queryName>cmis:objectTypeId</cmis:queryName>
<cmis:description>Id of the object’s type</cmis:description>
<cmis:propertyType>id</cmis:propertyType>
<cmis:cardinality>single</cmis:cardinality>
<cmis:updatability>oncreate</cmis:updatability>
<cmis:inherited>true</cmis:inherited>
<cmis:required>true</cmis:required>
<cmis:queryable>true</cmis:queryable>
<cmis:orderable>true</cmis:orderable>
<cmis:defaultValue/>
</cmis:propertyIdDefinition>
But if I understood it correctly, this is something that is hardcoded somehow and can't be reproduced using the normal custom model functionality. Is this correct?
Thanks for your time.
So yes, there is a mix of hard-coding and mapping involved. The value comes from Alfresco, not OpenCMIS. But Alfresco hard-codes the "oncreate" updateability of cmisbjectTypeId and "maps" the protected=true flag to the updateability of "readonly". This is all done in order to be as near as possible to the CMIS interface specification as possible with regards to the end-user / client meaning of "protected". But technically speaking, internally in Alfresco, the protected flag has no special meaning.
You can find this naiive interface mapping in the source of the data model sub-project.
Many thanks for clearing this up, we are still in the (long) process of learnig about Alfresco and CMIS, and sometimes we mix them, when they actually are totally separated things!
Ask for and offer help to other Alfresco Content Services Users and members of the Alfresco team.
Related links:
By using this site, you are agreeing to allow us to collect and use cookies as outlined in Alfresco’s Cookie Statement and Terms of Use (and you have a legitimate interest in Alfresco and our products, authorizing us to contact you in such methods). If you are not ok with these terms, please do not use this website.