Multi-Project Access Rights

Roles and Privileges Settings

Manage Roles and Privileges

The first step is to define company specific roles and privileged. A user that shall be permitted to create these data needs some basic permissions because the corresponding selections in the menu Manager>Permissions>Role Model are protected via the following privileges which have been added in Agile e6.

Function Menu Selection Required Privilege
Open privilege form to create/manage privileges Privileges
(EDB-ROL-OPEN-TASK)
EDB-ROL-PRV-OPN
Check privileges which are not assigned to any role and thus are freely available to every user Free available privileges
(EDB-ROL-FREE-TASK)
EDB-ROL-PRV-FRE-OPN
Open role form to create/manage roles Roles
(EDB-ROL-OPEN-ROLE)
EDB-ROL-OPN
Open job-function form to grant users a specific role Job-Functions
(EDB-ROL-OPEN-POS)
EDB-ROL-JOB-OPN
Open list "Privileges checked in Form" to define which privileges are required for standard operations (query, insert, copy, update, delete) in certain lists and forms.

Privileges checked in Forms
(EDB-ROL-MAS-TSK)

EDB-ROL-MAS-PRV-OPN

The new standard role EDB-ROLE-MNG (Role Manager) has access to these privileges and can thus manage roles, privileges, job functions etc.

In a company, the user that is granted this role is typically a person with a broad understanding of the business processes in the organization - possibly someone working at the management level or, alternativley, the system administrator.

 

Staffing a Project

Once PDW has been activated, the permissions are defined in a decentralized manner. Project managers staff their project by assigning the roles to the project team members (=job functions). This is done in the sub-list EDB-PRO-POS-CLI of the project form. Different from the standard Job Function form, the sub-list Project Team Members (which is a constraint list for the job functions) is available to all users. So it must be ensured that unprivileged users are not able to change the content of this list for in the worst case an ordinary user could assign and grant himself/herself the role "Project Manager". To avoid this, individual privileges are provided:

Function Operation Required Privilege
Create/copy project team member "I" and "C" in list
EDB-PRO-POS-CLI
EDB-POS-INS
Update project team member "U" in list
EDB-PRO-POS-CLI
EDB-POS-UPD
(Temporarily) Delete a project team member "T" in specific list in list
EDB-PRO-POS-CLI
EDB-POS-DEL

The new standard role EDB-PROJECT-MNG (Project Manager) has access to these privileges and thus can create, update and delete job functions (team members) in this sub-list. So a project manager is able to staff a project by assigning or removing team members. A project manager can even define project managers for sub-ordinate projects who then can staff the sub-projects themselves. Project Managers are normal users. They don't need to be DataView managers.

While these privileges ensure that only project managers (having the role EDB-PROJECT-MNG) define team members, it is additionally required to limit such users to changing the team members of a project where they are specifically assigned to as the project manager. For this reason, all of the privileges listed above need to be additionally limited with a rule. This rule will check if the user that currently tries to insert/copy/update or delete a team member is really the project manager for the current project or one of the higher-level projects.

The new standard role EDB-PROJECT-MNG (Project Manager) has also access to the following existing privileges which enable him/her to create sub-ordinate project hierarchies:

Function Operation Required Privilege
Create (subordinate) project "I" and "C" in entity
EDB-PROJECT
EDB-PRO-INS
Update project "U" in entity
EDB-PROJECTI
EDB-PRO-UPD
(Temporarily) Delete project "T" in entity
EDB-PROJECT
EDB-PRO-DEL

 

Create a top-level Project

While PDW allows a decentralized management of project specific permissions, there is one task that needs to be performed by a DataView manager: Creating a top-level project and assigning the project manager to it.

Top-level projects should be created by DataView managers because for these users PDW is not active. When creating a new top-level project this project does not refer to any other project. If an ordinary user would create a top-level project, this would automatically be related to the current active project - which is most likely not intended.
To create a top-level project the privilege EDB-PRO-INS is required. This privilege is included in the role EDB-PROJECT-MNG (Project Manager) which is granted to the DataView manager.