Roles and authorization

Authorizations are organized in roles. Roles can be seen as bundles of permissions to perform actions. Users are assigned a role to a specific object in the ITP/MDK Repository. For example, a user can be granted the role Project manager to a project, another user can be granted the role Text editor to a Text Block folder.

The idea is that users have a certain role within projects. There is usually a manager or project leader, several model developers, text editors, a reviewer of some sort and several guests (people who want to monitor the project but do no work). Every role requires certain capabilities, certain rights to do things, called permissions. For instance the project leader must be able to grant model developers access to the project, model developers must be able to edit documents etcetera.

When a user has no authorization on a folder or object, it will be hidden. This feature can, for example, be used to hide documents and models for users who only have the right to edit Text Blocks. If it is necessary for an object to be visible for the current user, it is enough to assign any role for a user on an object. To work with a visible object, still implies he needs to have enough rights on the specific object.

Keep in mind that all parent objects and folders must be visible to unhide information. Globally assigned rights, i.e., roles assigned by the Administrator in the configuration panel of the User, grant permissions on all objects in the ITP/MDK Repository, so in that case all objects and folders will be visible. Objects and folders that are considered to be relevant for the user and do not hinder him, such as in the case of usage relationships, are not hidden. For example, it can be useful for a user to see models that are in the 'used in' node of a Text Block.

Refer to the ITP/MDK Repository Administrator Manual for more information on creating roles, adding permissions and assigning a role to a user.

In general four rules apply to permissions:

1. Permissions or authorizations can only be granted to users through the assignment of roles.
2. No permission is granted by default (a new user has no roles).
   In other words, everything that is not expressly allowed is forbidden.
3. Permission is granted for a specific task on a specific (set of) object(s).
   Refer to the section below for more information.
4. Permissions cannot be suppressed.
   This is important because of the ITP/MDK Repository wide, global level of role assignment. If a role is assigned to a user, in the users Configuration window by the administrator, the user will have this role ITP/MDK Repository wide. This opens up the possibility to set permissions for the ITP/MDK Repository as a whole if you do not want to use the authorization mechanism.

Roles must be created before they can be assigned. The ITP/MDK Repository comes with a set of predefined roles.