Permissions are settings that determine whether a certain privilege will be granted to a certain profile or role. Unlike privileges, of which there are many, there are only two possible values for permissions: allowed and undefined (see figure below).
An “allowed” value for permission to a certain privilege explicitly grants access to this privilege for a certain profile or role.
An “undefined” value for permission to a certain privilege blocks access to the privilege – that is, the “closed philosophy” security notion will be adopted: that which is not explicitly allowed cannot be performed.
Note: Explicit denial ("prohibited") to a permission is not used.
In the example in the table below, Profile 1 received explicit permission ("Allowed") in Privilege 2 and 3, as well as "Undefined" permission in Privilege 1 and 4. As the system's philosophy is closed, it means that Profile 1 does not have permission in Privilege 1 and 4.
Privilege 1 |
Privilege 2 |
Privilege 3 |
Privilege 4 | |
Profile 1 |
Undefined |
Allowed |
Allowed |
Undefined |
Profile 2 |
Allowed |
Allowed |
Allowed |
Undefined |
Profile 3 |
Allowed |
Allowed |
Allowed |
Allowed |
Note: Permissions inherited by being assigned to a role are effective immediately, while permissions granted by inclusion in an access profile are only valid on the next login. If, for example, a person is assigned as project leader, the permissions related to this role go into effect once assigned. However, if the person is included in the Global Administrators profile, the permissions will only go into effect the next time this user signs in to the system.