Modifying Default Permissions Granted to Roles

A role will always have a direct relationship with some system object. It is through this relationship that it is possible to dynamically grant permissions to people or groups assigned to roles. Below are some examples of how this works.

Example 1:

1.    An asset is an object with an attribute known as “Responsible”.

2.    The “Responsible” attribute of an asset may be a person. That is, a person can be assigned to perform the Responsible for Asset role – in this case, XYZ asset.

3.    While exercising this role, the person in question automatically receives permission to change the properties of XYZ asset for which this person is responsible (but not other assets).

Example 2:

1.    A risk management project is an object with an attribute known as “Leader”.

2.    This “Leader” attribute in a risk management project may be a person. That is, a person can be assigned to perform the Leader of a Risk Management Project role for a certain project – in this case, XYZ project.

3.    While exercising this role, the person in question automatically receives permission to the Analyze Asset Risks privilege, and may perform activities related to analyzing risks in XYZ project to which the person was assigned as the leader (but not other projects).

Similarly, many system privileges also have a direct relationship with some object. For example, the Publish Surveys privilege is related to surveys, and the Close Risk Management Projects privilege is related to risk management projects.

In the system, default permissions granted to roles may be freely customized by authorized users. However, due to the relationships mentioned above (roles always have relationships with some system object, and many privileges also have direct relationships with certain objects), there are some restrictions to modifying default permissions granted to roles.

In general, if a permission was not granted by default to a role in a privilege (permission is “undefined”), then it may be that there is no relationship between the role and the object referenced by the privilege. In the example below, we have a privilege (Publish Surveys) which refers to the “survey” object, and we have a role (Responsible for Asset) which refers to another object (“asset”). By default, the Responsible for Asset role does not have permission to the Publish Surveys privilege, nor does it make sense to grant this permission since the role refers to a different object. Thus, the system will not allow the default permission to be modified from “undefined” to “allowed”.

Example 3:

Now imagine that the privilege is the same, but the role is Responsible for Surveys. Both the privilege and role now refer to the same object. Even though the Publish Surveys permission will not be granted by default to the Responsible for Surveys role, it makes sense that it can be granted and thus the system will allow it.

Example 4:

In Example 5 below, the Cancel Risk Management Projects permission is not granted by default to the Leader of a Risk Management Project role, but can be, since both the role and the permission concern the same object (in this case, a risk management project).

Example 5:

And lastly, there are cases when a permission to a certain privilege is granted by default to a certain role. In this event, the permission can always be removed. In Example 6 below, the Edit Surveys permission is granted by default to the Responsible for Surveys role. However, you can remove this permission if necessary and, in this case, the Responsible for Surveys role will no longer be able to edit surveys, not even those assigned.

Example 6:

In short, default permissions granted to profiles can be freely modified, while default permissions granted to roles can only sometimes be modified. The ability to edit a default permission for a role will depend on the nature of the role and of the privilege involved – that is, if both refer to the same object, or to different objects.