Rights Management
Information
- This topic provides detailed information on the working principles of rights management. It is especially intended for project management administrators who want to learn how to manage user rights.
- A short, general introduction to the rights concept of PLANTA as well as a description of how users can find out which user rights they possess can be found here.
Information
- In PLANTA project, rights management takes place at two levels:
- Rights Management for Modules and Menu Items. This is done via role assignment.
- Rights control for planning objects, portfolios, resources, and skills, i.e. which data a user may see, change, or delete in the modules made available to them. This is done via user parameters.
Rights Control for Modules and Menu Items Management via Role Assignment
Roles and work areas
In PLANTA project, roles are grouping units which are used for rights management. A role gives the users to whom it is assigned access to one or more groups of modules and menu items. Such groups are called work areas.
A work area consists of at least one module or menu item, however, usually they are composed of several modules or module panels and/or menu items. There are pure module work areas and pure menu item work areas.
Details
- Roles and work areas are created, adjusted and assigned to individual users by project management administrators.
- For this purpose, project management administrators only need access to the modules in which they want to make the changes. No further authorization is needed.
- Roles and work areas are managed in the Roles and Work Areas modules.
- The assignment of roles to users is carried out in the Users module.
- For this purpose, project management administrators only need access to the modules in which they want to make the changes. No further authorization is needed.
Example 1: | Example 2: |
---|---|
User 1
| User 2
|
Details
- It is possible to structure roles via Drag&Drop copying.
- Structuring can be used to increase clarity. It has no impact on access rights.
unstructured | structured |
---|---|
|
|
Notes
- The scope of supply of PLANTA project includes several predefined standard roles.
- They can either be assigned to the users as they are or they can be adjusted individually.
- If PLANTA demo data is installed, the standard roles can be opened via standard user. A list of standard users can be found here.
Rights control for planning objects, portfolios, and resources/skills via user parameters
Access Rights/Read-Only
Objective
- The system must be able to control access to resources/skills, planning objects (ideas, proposals, projects, programs), and portfolios, e.g. to make sure
- that an employee from department A cannot simply see projects or information from department B, or
- that a project manager only uses resources for his/her project which are from his/her own department.
- This way, the multi-client capability of the system is guaranteed.
Notes
- PLANTA project is configured in such a way that when one has access to a planning object or a resource, one can see the data of this object/these resources and select them, e.g., in listboxes.
- Modification rights are allocated explicitly via the settings of particular parameters. For more information, see the Modification Rights for Planning Objects, Portfolios, and Resources chapter.
Control Planning Object Access and Portfolios
Question
- How does the system know which planning objects a user is allowed to see?
Answer
- This is achieved by using the cost center structure code.
- Each planning object is assigned to a particular cost center.
- A structure code is assigned to each cost center.
- For each user it is specified to which cost center structure code he/she has access.
- In all analyses and listboxes in which projects are selected it is checked whether the structure code which is stored on the user coincides with that of the project. From a data point of view this is solved via the @53 system variable as a filter criterion on the Cost center structure code field.
Procedure
- Create required cost centers/organizational units in the Cost Centers module under PM Administration → Master Data → Costs and allocate a structure code for each cost center.
- Assign planning objects to cost centers To do so,
- enter the cost center to which the planning object belongs in the Cost center field of the respective planning object (Project Core Data, Idea Core Data, Proposal Core Data, Portfolio Core Data).
- Assign cost center structure codes to users To do so,
- Open PM Administration → Master Data → Users, Roles, Resources and open the Users module.
- Enter the structure code of the cost center to the planning objects of which the user has access in the Object access field or enter the structure code area (by using wildcard *) in case the user has access to different cost centers.
- An asterisk (*) means: all following sub-points of the item marked with the asterisk.
Users | Values in the Objects access field | Meaning |
---|---|---|
A | 01 | User A can access the planning objects the cost center of which has structure code 01. |
B | 0112* | User A can access the planning objects the cost center of which has the structure code that starts with 0112. |
C | * | User C can access all planning objects. |
D | blank: | User D can access all planning objects. |
E | String which does not correspond to any valid structure code (e.g. x) | User E cannot access any planning objects. |
Control Resource/Skill Access
Question
- How does the system know which resources/skills are to be displayed/available for selection to the logged-on user?
Answer
- This is achieved by using the resource/skill structure code.
- Each resource /each skill receives its own structure code.
- To each user, the structure code to which he/she has access is assigned.
- In all analyses and listboxes in which resources/skills are selected, all resources/skills are searched which possess the resource structure code/skill structure code to which the current user has access. From a data point of view this is solved via the @32 system variable as a filter criterion on the Resource structure code and Skill structure code field.
Procedure
- Enter Structure Codes and Resources and Skills
- The resource structure code is allocated manually in accordance with the respective resource structure/company structure in the Resource structure code field in the following modules:
- The skill structure code is allocated manually in accordance with skill structure in the Skill structure code field in the following modules:
- Assign structure codes to users
- Open PM Administration → Master Data → Users, Roles, Resources and open the Users module.
- Enter the structure code of the resource to which you want the user to have access in the Resource access field or enter the structure code area (by using wildcard *) in case the user has access to different cost centers.
- An asterisk (*) means: all following sub-points of the item marked with the asterisk.
- The resource structure codes displayed in the eponymous column can be used as a reference for setting the appropriate resource structure code in the Resource access field. Furthermore a traffic light is implemented on the Resource structure code column which turns yellow when the values specified in the Resource access field do not correlate with the resource structure code.
Users | Values in the Resource access field | Meaning |
---|---|---|
A | 1 | User A can access all resources/skills the structure code of which is 1. |
B | 1.1.2* | User B can access all resources/skills the structure code of which starts with 1.1.2, i.e. also 1.1.2.1 or 1.1.2.2.1 |
C | * | User C can access all resources/skills. |
D | blank: | User D can access all resources/skills. |
E | String which does not correspond to any valid structure code (e.g. x) | User E cannot access any resources. |
Note
- Since access to both resources and skills is currently controlled via the same parameter (Access to resources), you should make sure that the structure codes of resources and skills to which the user is to have access coincide.
Note for PLANTA Hybrid
- The resource access defined in PLANTA project also takes effect when using PLANTA Hybrid. A user can, e.g., record hours worked in PLANTA pulse for resources to which he/she has access in PLANTA project.
Department Manager
Information
- In order to control the display of department resources for the department manager in the My Department and Planning modules, the Department parameter is used in addition to the Resource access parameter. In this parameter, the department for which the user assumes management rights (department rights) is stored.
Details
- The Department parameter does not necessarily have to be the department to which the user belongs. You can also enter a superordinate department if the user is to be responsible for all subordinate departments. In such a case, please make sure that the correct structure code is entered in the Resource access field, so that it does not contradict the entry made here and possibly restricts resource access.
- The structure code of the department entered here has to be identical to the value in the Resource access field or the value in Resource access must imply the structure code of the department entered.
- Example: If the structure code of the entered department is 1.4.1, the entry in Resource access must be 1.4.1, 1.4.1*, 1.4* or 1*.
- The structure code of the department entered here has to be identical to the value in the Resource access field or the value in Resource access must imply the structure code of the department entered.
- For all users to whom the resource manager role is assigned it is mandatory to specify a department since otherwise the department board cannot be opened.
Modification Rights
Information
- In PLANTA project, modification rights (creation, editing/changing, deletion) for planning objects (projects, programs, ideas, proposals), portfolios, and resources are controlled via several parameters.
- Object rights in the Users module
- Manager in the core data module of the respective planning object (Project Core Data, Program Core Data, Proposal Core Data) or Portfolio manager in the Portfolio Core Data. For ideas, the Manager field is not contained in the core data module, so that the idea manager can only be changed in the Edit Planning Objects module can be changed in the Ideas module variant.
- Modification access in the Stakeholder area in the core data module of the respective planning object (Project Core Data, Program Core Data, Proposal Core Data).
- This results in the following rights groups which can be defined using the following parameters:
- No manager / project team members
- Object rights = 0 and
- not defined as Manager of the respective planning object and
- not defined as Stakeholder with modification rights of the respective planning object
- (Stakeholder with Modification Rights)
- Object rights = 0 and
- not defined as Manager of the respective planning object, but
- defined as Stakeholder with modification rights of the respective planning object
- Portfolio Managers
- Object rights = 0, but
- defined as Portfolio manager of the respective portfolio
- Multi-project manager
- Object rights = 1
- Multi-portfolio manager
- Object rights = 2
- No manager / project team members
- Please refer to the following matrix to find out which specific authorizations these groups have:
No manager / project team members | Idea manager | Proposal manager + Deputy | Subproject manager + Deputy | Main project manager /project manager + Deputy | Program manager + Deputy | Portfolio manager | Multi-project manager | Multi-portfolio manager | |
---|---|---|---|---|---|---|---|---|---|
Read | X | X | X | X | X | X | X | X | X |
Create ideas | X | X | X | X | X | X | X | X | X |
Create proposals | X | X | X | X | X | X | X | X | X |
Create projects | X Only subprojects | X | X | ||||||
Create programs | X | X | |||||||
Create portfolios | X | ||||||||
Create resources | X | X | |||||||
Edit ideas | X1 | X1 | X1 | X1 | X1 | X1 | X1 | X | X |
Edit proposals | X1 | X1 | X1 | X1 | X1 | X1 | X1 | X | X |
Edit projects | O | X1+2 | X1+2 | X | X | ||||
Edit programs | X1+2 | X | X | ||||||
Edit portfolios | X1 | X | |||||||
Edit resources | X | X | |||||||
Delete ideas | X1 | X1 | X1 | X1 | X1 | X1 | X1 | X | X |
Delete proposals | X | X | |||||||
Delete projects | X | X | |||||||
Delete programs | X | X | |||||||
Delete portfolios | X1 | X | |||||||
Delete resources | X | X |
- X - Rights without restriction
- X1 - Editing or deletion rights only for own planning objects, i.e. for which he/she is manager or deputy (stakeholder with modification access),
- X1+2 - Modification or deletion rights only for own planning objects and additionally the following restrictions (no authorization for this function):
- change functional ID of the planning object
- approve the requested budget
- lock project when the project is already unlocked
- X1+2 - Modification or deletion rights only for own planning objects and additionally the following restrictions (no authorization for this function):
- O - No editing rights for planning objects except recording of actual hours on tasks. However, this is done in the course of time recording in special modules and not directly in the planning objects.
Special right: Deletion of actual postings
Information
- In PLANTA, posting records or simply postings are actual load records with actual data (actual hours, actual costs, and actual revenues).
- For the user which is to be granted the right to delete load records, the Can delete actual postings checkbox must be activated in the Users module.
- The same applies to the user who wants to delete projects with actual postings (multi-project manager rights alone are not sufficient).
Caution
- PLANTA expressly advises against the deletion of entire posting records. Instead, Reverse Postings should be recorded.
- Reason:
- The effect of the key date is levered out since records which have a date earlier than the key date can also be deleted.
- The deletion of exported/imported posting records leads to inconsistencies between external system and PLANTA.
- The deletion of posting records which have already undergone a scheduling has an impact on the calculation of remaining values.
- Explanation: As soon as an actual load value has been recorded, the Remaining value on the resource assignment (DT466) is reduced accordingly.
- If only the actual load value is deleted, scheduling will readjust (i.e. increase) the remaining value on the resource assignment (DT466).
- If, on the other hand, the entire actual load record is deleted, the already reduced remaining value on the resource assignment (DT466) remains unchanged.
- Explanation: As soon as an actual load value has been recorded, the Remaining value on the resource assignment (DT466) is reduced accordingly.
- Reason:
- If actual load records are to be deleted anyway, remaining effort/remaining costs/remaining revenues and actual start date entries must be verified and possibly be corrected manually.
Customizer Rights Group
- Customizer rights are allocated by activating the Customizer parameter in the Users module. These rights entitle the user to change customizing parameters or to even delete the entire module customizing to which he/she has access. This is the case regardless of whether the user has modification rights for project data.
- Furthermore, users with customizer rights possess all modification rights at user level, regardless of other rights which may be defined for them.
- Via the functions of the customizer, a user with customizer rights can edit and delete any record (including entire planning objects).