To summarise what's to be done here:
- we already have a HiddenObjectFacet (currently derived from a "hidden()" method on the object itself) that can be installed on the ObjectSpecification. Make it a viewer responsibility that if this exists, hide any collections for that ObjectSpecification.
- create a further implementation for this facet that is derived from the set of permissions : if all props are invisible, infer that the object as a whole is.
- as belt-n-braces, implement a general tenancy evaluator that hides an object if its ObjectSpecification has this facet.
- similar to the work done in
ISIS-2701, we'll should also introduce an `ApplicationUser_effectiveTypePermissions` mixin to surface this computed set. Only secman admins should be able to see this collection.
some of the discussion leading to this outcome below (and for the original discussion, see https://the-asf.slack.com/archives/CFC42LWBV/p1621939985113300 )
A permission that vetoes the viewing of a type (such as in the example below) is not fully honored. In this concrete case a user that is being assigned a role with this permission (and no other roles with any permission that would contradict this permission) could still navigate to an entity page of a ApplicationUser and would see the title and the the icon and perhaps an empty metadata tab.
The desired behavior would be the display of an error message saying "Not authorized or no such object".
This is a screenshot of how the vetoed entity page presents to the user: