Affects Version/s: V4.01_OS
Fix Version/s: None
Allow annotating capabilities at entity types, so paths can be expressed per the Item instance:
Extend AppliesTo list to include EntityType, and add to description that this "escape hatch" should only be used for dynamic capabilities depending on a property of a related type.Allow annotating capabilities at entity types, so paths can be expressed per the Item instance: <Annotations Target= "MyService.Item" > <Annotation Term= "Capabilities.UpdateRestrictions" > <Record Type= "Capabilities.UpdateRestrictionsType" > <PropertyValue Property= "Updatable" Path= "isUpdatable" /> </Record> </Annotation> </Annotations> Extend AppliesTo list to include EntityType , and add to description that this "escape hatch" should only be used for dynamic capabilities depending on a property of a related type.
Capabilities are annotated on entity sets, and for "nested" / contained entities they are expressed via Capabilities.NavigationRestrictions.
This works fine for static capabilities (can't ever update, can't ever delete), but does not allow expressing dynamic capabilities via boolean properties on the nested entities.
- Orders have (contained) items
- Each Item has a property isUpdatable
The corresponding navigation restriction is (rather bulky):
Unfortunately the above annotation is also wrong, because 126.96.36.199 Path Evaluation states
For annotations embedded within or targeting an entity set or a singleton, the path is evaluated starting at the entity set or singleton, i.e. an empty path resolves to the entity set or singleton, and non-empty paths MUST follow the rules for annotations targeting the declared entity type of the entity set or singleton.
This means that the annotation would have to use Path="items/isUpdatable" which is a collection of Boolean values and thus not type-compatible with the Updatable property, and the connection to the concrete item that is to be updated is lost.