Most areas of IRM administration are quite straightforward and require no further overview information to be effectively utilized. However, the Permissions / access control area is a bit more complex and requires further introduction so that administrators can make the best use of its considerable capabilities to assign permissions in the simplest ways while avoiding potential performance issues.
Elements of the permissions model
Only Admins can assign permissions via the Global Console and change the definitions of Groupings that are used by Policies.
An IRM User or User Team has no permissions unless they are explicitly granted.
Permissions are purely additive. There are no “negative” or "subtractive" permissions.
All users automatically have read permissions on all Library-level objects (Categories, Types, and Type helpers).
IRM supports two kinds of permissions: read access and write access. IRM does not distinguish the individual subtypes of write permissions (create, edit, and delete).
Read permissions are controlled exclusively though the "Viewable areas" list in the Site Grouping.
Each Area checked in the "Viewable areas" list allows read access to that Area and all objects contained in that Area.
A Site Grouping grants write permissions for all the objects specified by its underlying Grouping and for objects indicated by its Shortcut Permissions for specific Categories and Lifecycle Super Stages.
A Policy can be assigned to directly to any number of IRM Users and/or User Teams.
An IRM User or IRM User Team can have any number of Policies assigned to it.
A Grouping that has been referenced by an Site Grouping is specially distinguished from other Groupings. Such a Grouping can only have its definition changed by an Admin IRM User. In addition, all Groupings and Filters directly or indirectly referenced by a distinguished Grouping can only be modified by an Admin. These restrictions are necessary to ensure that ordinary IRM Users cannot give themselves additional access by modifying the Groupings used to control permissions.
Assigning a Policy to a User Team is completely independent of assigning the Policy to IRM Users directly. The same Irm Policy can be assigned to an Irm User and also to any Irm User Groups that the Irm User is in, without the assignments impacting each other.
If an IRM User (or a User Team) has a permission for a containing object, the User implicitly has the permission for all contained objects. For example, if there is a Policy with permission for a Grouping that contains an Area X, and that Policy is assigned to an 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”. For example, a User could be given a permission for an object directly, and also via the Area or Site that the object is in, or via a User Team that the User is in. As long as the User has the permission needed for an operation by some route, the User can do the operation.
Irrespective of who created the object, if the assigned role or permission does not grant a user access to the object that should be the overriding factor as to who can edit or delete the object. The person who created it
is for audit purpose only. For example, a user will have access to the object until a certain period of time expires (24 hours), after which the Edit, Delete access resorts back to any current policy setting or restriction for that user.
Permissions summary
Users start only with read permission to Library objects (no other permissions) and permissions are purely additive.
Read permissions are assigned on an Area basis
Write permissions can be controlled down to the individual object level through the use of Groupings. However, administrators should make use of IRM's shortcut permissions where possible, as these are more effecient.
