Rights Management in PLANTA project

Information

• In PLANTA project, a distinction is made between two different levels of rights management:
  • Rights management via role assignment. Via role assignment, a user is given access rights to certain modules and menu items.
  • Rights management via user parameters. Via user parameters it is defined which data a user is actually allowed to see in the modules provided to him/her and what he/she is permitted to do with this data (read and/or write).

Rights Management via Role Assignment

Users

• Access to certain modules and menu items can be given to users
  • This is done by assigning the required modules and menu items to a user.
    • The assignment is not made directly but in groups. Elements via which modules and menu items are grouped are work areas and roles.

Roles

• A role consists of a work area or of a combination of various work areas.
• A menu item role is a role to which a menu item work area is assigned.

Work areas

• A work area consists of a module or of a compilation of various modules.
• A menu item work area is a work area in which various menu items are compiled.

Details

• The assignment is done in the Users module by a user with access to this module (usually the administrator). Here, no special user rights are required.
• On the graphical user interface,
  • menu items are in the menu bar or in the toolbar
  • roles and work areas can be found in the user menu.
  • Below the work areas there are links to the modules or thematic module groups called panels.

Assignment examples

Example	Example 2
User 1 Role 1 Menu item work area 1 Menu items a, b, c Role 2 Work area 1 Module 1 Module 2 Module 3 Work area 2 Module 5 Module 6 Role 3 Work area 3 Module ... Work area 4 Modules ... Role 4 Work area 5 Modules ...	User 2 Role 10 Menu item work area 20 Menu items x, y, z Role 2 Work area 1 Module 1 Module 2 Module 3 Work area 2 Module 5 Module 6 Role 5 Work area 6 Modules ...

Details

• It is possible to structure roles via Drag&Drop move.
  • Structuring can be used to gain more clarity and has no influence on access controlling.

Example of structuring

unstructured	structured
User x Role A Work area 1 Work area 2 Work area 3 Work area 4	User x Role A Role B Work area 1 Work area 2 Role C Work area 3 Work area 4

Notes

• Several predefined roles are included in the scope of supply of the PLANTA software.
  • They can be copied without changes and can be assigned to users or be adapted and changed individually.
• The PLANTA Standard users are only available if PLANTA demo data is installed.
  • These standard users contain assignments of PLANTA Standard roles.

Rights Management via User Parameters

Access Rights (Read Rights) for Planning Objects and Resources

Objective

• The system must be able to control resource access and planning objects at any time, e.g.,
  • a manager may only use resources from his or her own department for his or her projects or
  • someone from department A may not view projects or information from department B.

Note

• Due to the configuration of PLANTA project, users that can access a planning object or a resource automatically have read rights for this object/resource. Write rights are allocated via settings of particular parameters. For more information, see the Write Authorizations for Planning Objects and Resources chapter.

Control Access to Planning Objects

Information

• It is essential for the system to recognize, which planning objects can be seen or edited by logged-in users.
• Access authorization must be based on a hierarchy, as cross-organizational access possibly needs to be ensured.
• Access restriction becomes particularly necessary when multi-project management is carried out in large organizational units.

Question

• How does the system know which planning objects a user is allowed to view?

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 which cost center structure code he or she has access to.
  • All analyses and listboxes in which projects are selected check whether the structure code that is stored for the user matches that of the project. From a data point of view, this is solved by using the @53 system variable as a filter criterion on the Cost center structure code field.

Assign structure codes to cost centers

• Open PM Administration Master Data Cost Centers
• Enter a structure code for each cost center.

Assign cost centers to planning objects

• Enter the cost center to which the planning object belongs in the Cost Center field in the core data of the respective planning object (Project Core Data, Idea Core Data, Proposal Core Data).

Assign cost center structure codes to a user (control of display/selection)

• Open PM Administration Master Data Administration and open the Users module.
• Enter the corresponding structure code in the Project access field of the required user.
• An asterisk (*) accordingly means: all following subitems of the item marked with an asterisk.

Examples for possible entry in the Access to projects field and its meaning

User	Value in the Project access field	Meaning
A	01*	User A has access to planning objects the cost center of which has a structure code that begins with 01.
B	0112*	User B has access to planning objects the cost center of which has a structure code that begins with 0112.
C	*	User C has access to all planning objects.
D	empty	User D has access to all planning objects.
E	String which does not equate to any valid structure code (e.g. x)	User E cannot access any planning objects.

Control Resource/Skill Access

Department Manager

Information

• To control the display of the department resources for the department manager in the My Department and Planning modules, the Department parameter will be used in addition to the Access to resources. In this parameter, the department for which the user assumes manager rights (department rights) are stored.

Details

• The department entered here does not necessarily have to be the department the user belongs to (see parent resource field in the Resource Data Sheet). The structure code of the department specified here has to match the structure code of the resource which the user is permitted to access, hence with the value in the Access to resources field. More specifically the value is to imply the structure code in the Access to resources field. E.g.: If the structure code of the department is 1.4.1, the entry in Resource access must either be 1.4.1, 1.4.1*, 1.4* or 1*.
  • If the department structure code is identical to the value in the Resource access field, only this department and its resources are displayed in the My Department module.
  • The department utilization diagram is displayed in the My Department module if the value in the Resource access field implies the department structure code, however, all resources to which the user has access are listed.
  • If completely different values are entered in each field, no department utilization diagram is displayed in the My Department module, but all resources to which the user has access are displayed.
• If no department is specified in the Department parameter, but the Resource management role with the Department board is assigned to the user, a message will be displayed when attempting to open the department board and the modules contained in the department board will not be loaded.

Write Rights (Modification Rights) for Planning Objects and Resources

Information

Attention

• Users for which the Customizer checkbox in the Users module is activated have all write rights (regardless of any deviating definition in other rights parameters) in all planning objects to which they have access.

Name	Necessary Settings	Rights
No manager rights	Object rights = 0 not defined as Manager of the planning object not defined as Stakeholder with modification access	Only read data of the planning objects (except ideas and proposals) in modules to which one has access Creation, editing, and deletion of ideas and proposals possible For newly created ideas and proposals, the creating user is automatically entered as the manager, so that he/she also receives rights for editing these objects. For this purpose, see Idea manager and Proposal manager

PLANTA project

Subproject manager	Object rights = 0 defined as manager of the subproject or as a stakeholder with modification access	Modification of own subprojects only
(Main) project manager deputy	Object rights = 0 defined as manager of the (main) project or as a stakeholder with modification access of the (main) project	Editing of own (main) projects only Creation, modification, and deletion of subprojects
Program manager	Object rights = 0 defined as manager of the program or as a stakeholder with program modification access	Editing of own programs only
Idea manager	Object rights = 0 defined as a Manager of the idea	Modification and deletion of own ideas only
Proposal manager	Object rights = 0 defined as manager of the proposal or as a stakeholder with proposal modification rights	Modification and deletion of own proposals
Multi-project manager	Object rights = 1	Creation, modification, and deletion of (main) projects, subprojects, ideas, proposals, programs, and resources If project administrators are to create resources, they require this authorization.

PLANTA portfolio

Portfolio manager	Object rights = 0 defined as a portfolio manager of the portfolio	Modification of own portfolios only
Multi-portfolio manager	Object rights = 2	Creation, modification, and deletion of (main) projects, subprojects, ideas, proposals, programs, and resources + Creation, modification, and deletion of portfolios

PLANTA request

Request manager	Object rights = 0 defined as a manager of the request or as a stakeholder with request modification rights	Editing of own requests only
Multi-request manager	Object rights = 3	Creation, modification, and deletion of requests

Overarching

Multi-project/request manager

Object rights = 4

Creation, modification, and deletion of (main) projects, subprojects, ideas, proposals, programs, and resources + Creation, modification, and deletion of requests

Special Rights

Authorization to Delete Posting Records

Information

• In PLANTA, posting records, or simply postings, are actual load records (actual hours, actual costs, and actual revenues).
• The user needs Authorization = 32 or 35 in order to be able to delete posting records. You can find this parameter in the Users module.
  • The same applies to the user who wants to delete the projects with actual postings (multi-project management rights alone are not sufficient).

Attention

• PLANTA strongly advises against the deletion of posting records and instead advises to record reverse postings.
  • Explanation
    • The effect of the key date is canceled since records which lie before the key date can also be deleted.
    • the deletion of exported/imported posting records leads to inconsistencies between the external system and PLANTA.
    • The deletion of already scheduled posting records has an impact on the calculation of the 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 the actual load value is now deleted, the Remaining value on the resource assignment (DT466) is adjusted accordingly again, i.e. it is increased.
        • If, on the other hand, the entire actual load record is deleted, the already reduced Remaining value on the resource assignment (DT466) remains unchanged.

• If actual reports are to be deleted anyway, remaining effort/remaining costs/remaining revenues and actual start date entries must be checked and corrected if necessary.

---

See also: Field Types, How to Operate PLANTA project, Multilingualism, Getting Started