a list of Groupings and “all objects” shortcut flags that together define a list of objects in a single Site, against which we wish to make a policy
Policy
a named list of Site Policies and top-level “all objects” flags
Rules regarding permissions and policies
There are two types of permissions: read/view and write. IRM does not track the individual subtypes of write permission (add, edit, and delete) separately.
An IRM user or User Team has no permissions unless they are explicitly granted.
Permissions are purely additive. There are no “negative” permissions.
All IRM users automatically have read permissions on all Library objects (Categories, Types, and Type helpers)
A Policy grants read/view permission on the Areas listed in it, and all objects contained in those Areas.
A Policy grants write permissions for the objects specified in the Policy’s Groupings (which are specified in its Site Policies).
Any given Policy can be assigned to any number of IRM users and/or IRM user groups.
Any IRM User or User Team can have any number of policies assigned to it.
Any number of Policies can be written against a single Grouping.
A Grouping that is referenced directly or indirectly by a Policy can only have its definition changed by an Admin IRM user.
Assigning a Policy to an IRM user group is completely independent of assigning the Policy to any IRM users directly. The same Policy can be assigned to an IRM user and also to any IRM user groups that the IRM user is in, without any of the assignments impacting each other.
Permissions are inherited by “contained” objects from their containing objects. That is, if an IRM user (or IRM user group) has a permission for a containing object, the IRM user implicitly has the permission for all contained objects. For example, if there is a Site Policy with a Grouping that contains an Area X, and that Policy is assigned to an IRM user, then that user has permission for the Area and all objects contained in the Area (Lines, Equipment, Cables, Pathways, etc.)
An IRM user can get the same permission via many different “routes” or “paths”. This is not a problem. For example, an IRM user could be given a permission for an object directly, and also via the Area or Site that the object is in, or via an IRM user group that the user is in. As long as the IRM user has the permission needed for an operation by some route, the user can do the operation.
