The CR creates a default folder called 'Pages' with object_id=-100. Other apps use this folder as a parent (photo-album, etp).
According to the permissions documentation:
The object default_context represents the root of the context hierarchy for the entire site. All permission searches walk up the tree to this point and then stop. If you grant permissions on this object, then by default those permissions will hold for every object in the system, regardless of which subsite they happen to live in.
But the CR 'Pages' folder circumvents this hierarchy by inheriting directly from security_context_root (id=0), instead of default_context (id=-3). This becomes an issue when other packages (i.e. general-comments) give privileges to users on the default_context, but then those privileges don't get translated to places like photo-album and etp who inherit from 'Pages' and thus from security_context_root.
Current situation:
0 ---- -100 (Pages) --- Photo-Album
|
|
-3 (gc-create)
|
|
other site objects
Should be:
0
|
|
-3 (gc-create) ---- -100 (Pages) --- Photo-Album
|
|
other site objects
Object -100 should inherit from -3. I don't think anything should directly inherit from object 0 (except object -3, of course). If you want to circumvent the context hierarchy, you can set
security_inherit_p to false.
