In every project, users are assigned various roles with different responsibilities. These are:
1.Project leader (person in charge)
2.Deputy of the project leader
3.Leader of an activity group (stage)
4.Deputy of an activity group (stage)
5.Leader of an activity
6.Deputy of an activity
7.Supervisor A (yet to be introduced)
8.Supervisor B (yet to be introduced)
Users can have specific access rights automatically assigned according to their role in the particular project.
|
Example: The user opens Project A where they are the project leader. They will get significant access rights (i.e. less restrictions). The same user then opens Project B where they are in charge of an activity. In this project, the user will be more restricted. |
The permission groups are predefined, but the specific permissions/accesses of these groups have to be defined by the administrator. The permissions work hierarchically from the project leader (highest access level) to the activity deputy (lowest access level). One user can have multiple project roles so that if the project leader is also a deputy of one of the project activities, they will not be restricted samely as any other activity deputy.
The administrator does not need to assign these project groups in the profiles of the involved users (unlike with standard permission groups). They will be assigned automatically according to their role in the specific project.
In the following image, you can see the predefined project permission groups highlighted.
|
Important: The access permissions are cumulative. If a user is also a member of another permission group that has more permissions than specified for their role, they will have these additional permissions as well. Thus the role restriction will be ineffective. |
