Access Policies via Models

Examples

1. Given the myns:image object, I want to create some access policies that allow only users in imaging group to view and update that object.
2. If a user adds the mymix:published_web mixin, access to that object, some of its properties, and the web_thumbnail, web_small and web_large datastreams is granted to web users. 
3. If a user removes the mymix:published_web mixin, access to the object, all its properties and children is revoked for all web users.

Content Model API

Object Services

Examples

1. 1. Given the myns:image node above, I want to run a method (sequencer?) that creates/updates a thumbnail datastream under it every time the master datastream is updated. 
   2. The myns:image type constraints assures that master is always present so if a new myns:image is created, a master child is expected to run the method on.
   3. Some users should be able to attach a pre-defined mymix:published_web mixin to the same object; when that happens, a sequencer is there waiting to create aweb_thumbnail, a web_small and web_large datastreams as children of the object. 
   4. Conversely, if the user removes mymix:published_web, the web_thumbnail,web_small and web_largedatastreams are destroyed. 

Challenges

1. How do we handle the creation process so that the object does not go through validation before all mandatory children are ingested? 

Issues / limitations

1. A mixin can define a mandatory type, but the mixin itself is not mandatory. If some editor removes the mixin, that would break the thumbnail method. In order to prevent that, access policies can be defined for who can remove or add a certain mixin; but for basic functionality not meant to be ever removed, a primary type would solve the problem more easily and elegantly. 

• Stefano Cossu: tests should be made with transactions for Challenge #1 when https://www.pivotaltracker.com/s/projects/684825/stories/64058980 is fixed. If I am able to create a node with a primary type or mix-in that defines a mandatory child , and that child as well within a transaction, and the validation is performed ONLY after the transaction is committed, this would solve the issue. 

Structural Validation

Examples

1. I have a myns:image asset type that is auto-assigned to assets ingested by Imaging department. 
2. myns:image has mandatory properties and/or children such as a master datastream, of type nt:file or a subtype thereof.
3. myns:image assets can only have children of nt:file type. Ideally, that nt:file should be within a range of defined MIME types (not a critical feature for now)
4. I need a validation mechanism that throws an error if an user adds or updates a child or property that doesn't conform to that definition. 

Issues / limitations

1. The default primary type, nt:folder, allows all Fedora nodes to have children of any type, with any name, in any number. There is no way to restrict that with Fedora's current tools. 
2. The auto-assigned mixin type, fedora:resource, allows nodes to have properties of any type, with any name, in any number. Ditto as above. 
3. If a mix-in is removed that defines some properties and/or child nodes, currently these properties/child nodes are not removed. It is not easy to find which properties/child nodes were introduced by a content model, in order to "cleanly" remove it. 
   1. Bad solution: mirror the content model schema in the client systems that are adding/removing content models so they know which properties/children can be removed along with the content model.
   2. Better solution: expose content model schema via REST API methods (e.g. provide more details in /rest/fcr:nodetypes) 
   3. Another solution: provide a REST API method that automatically removes all properties/children before removing the content model (in one transaction, so no mandatory constraints are violated). 

Use case: AIC type hierarchy

att_D-AIC_JCR_classes.pdf

Structural Validation - Properties

Example

1. Given the myns:image object, I want to make it able to have any number of metadata children. Children should be of type myns:meta or a subtype thereof, and their name should start with meta_ (e.g. meta_exif, meta_geo, etc.)

Limitations

1. There is no way, even in CND, to achieve this.