For child associations that specify duplicate=false (like cm:contains in the type cm:folder), the NodeService API is supposed to enforce a uniqueness constraint regarding the cm:property over all child nodes of the same (primary) parent. This enforcement works for the operations createNode, setProperty, setProperties and addProperties, but can be circumvented via the addAspect operation.
The addAspect operation takes a map of property values which it will apply to the node being modified without regard to any relationship between the properties and the aspect (it is possible to pass ANY properties - they need not be defined by the aspect being added). When the map of property values contains a new cm:name value, that property is updated in alf_node_properties table but the uniqueness constraint is not checked / enforced.
Steps to reproduce:
- create a folder in the Repository view with name "XYZ"
- create a second folder with name "XYZ2" in the same location
- copy/remember the NodeRef of the second folder
Expected result: The script fails with a DuplicateChildNodeNameException
Observed result: The script succeeds and we end up with two folders with identical name.
As far as I can see this bug has been in Alfresco for a very long time (at least since 3.x). One might argue that addAspect should only be used to add aspect-related properties (developer mistake). But that operation never restricted the set of properties to be set and it should not start to now in order to maintain compatibility.
The only call missing in the addAspect operation is a call to the setPropertiesCommonWork internal operation that performs the proper update of the primary parent association based on cm:name.