Page History

...

root/  (default content roles, i.e. no roles for anyone)
├── object A  (EVERYONE => reader; johndoe => admin)
│   ├── datastream 1  (johndoe => admin)
│   └── object Q  (EVERYONE => reader; johndoe => admin)
│       └── object R (janedee => admin)    
├── object B  (EVERYONE => reader; johndoe => admin)
│   └── object T
│       └── object V
└── object C 

Order of operation:

...

This module assigns roles to generic security principals, i.e. any class that implements java.security.Principal. Roles are serialized and matched against the principal name, a string property of the principal. All the principals used in your repository environment must have unique names. Other than that, you may use whatever principals you wish. This module does not validate principal names.

Inheritance

Descendent nodes inherit the content ACLs of ancestor nodes only if they have no ACLs themselves.  If a node has content ACLs, the node ACLs override ALL ancestor ACLs.

The following examples, based on the graph shown above, demonstrate how inheritance plays out.

1. Datastream 1 of object A only allows one principal to access the node:  johndoe.  He will have admin privileges.  None of the ACLs on object A will be applied; the datastream will not inherit the EVERYONE => reader ACL on object A.
2. Object R, a child of object Q, has its own content ACL:  janedee has admin privileges on object R.  No one else has any access to the node, not even the parent node (object Q) principals (EVERYONE and johndoe).
3. Object T, a child of object B, has no content ACLs.  So it inherits the ACLs of its most immediate ancestor with content ACLs:  object B.  EVERYONE has reader privileges on object T, and johndoe has admin priivileges on the object.
4. Object V also inherits the ACLs of object B (its most immediate ancestor with content ACLs).
5. Object C has no content ACL;  it inherits the ACLs of the root node, which is to say, nothing.  No one other than fedoraAdmin has any access to this object.