Vergleichsreport

Diese Seite beschreibt die Maske This page describes the form po_editRole.act (erreichbar über die Rollen-Übersicht reached via the roles overview po_showRoles.act). Das Konzept dahinter – Kompetenzziele, Suchstrategie, Organisationstypen – ist im Kapitel Rollen beschrieben.

Berechtigung: Rollen anlegen, ändern und löschen darf nur, wer Systemadministrator ist oder eine Einsichtsberechtigung auf alle Mandanten besitzt. Lokale Administratoren sehen die Maske eingeschränkt: Die Felder Workflow-ID, Standardrolle, Badge und "Vor lokalem Administrator verbergen" sind für sie ausgeblendet, und es öffnet sich direkt der Reiter Rolleninhaber.

Anlegen einer neuen Rolle

• Neue Rolle: Maske befüllen und mit "Speichern" bzw. "Speichern & Schließen" bestätigen.
• Die Reiter (Workflow Optionen, Aktionen, Rolleninhaber, ...) erscheinen erst nach dem ersten Speichern.
• Gültig von / Gültig bis der Rolle können nur beim Anlegen gesetzt werden; danach werden sie nur mehr angezeigt.

Felder

The underlying concept – competence targets, search strategy, organization types – is described in the chapter Roles.

Permission: Only system administrators or users with a view permission on all clients may create, change or delete roles. Local administrators see a restricted form: the fields workflow ID, default role, badge and "hide from local administrator" are hidden for them, and the role holders tab opens directly.

Creating a new role

• New role: fill in the form and confirm with "Save" or "Save & Close".
• The tabs (workflow options, actions, role holders, ...) only appear after the first save.
• Valid from / valid to of the role can only be set at creation; afterwards they are display-only.

Fields

• Name (required, min. 2 characters)
  Name of the role. The system checks that the role does not already exist for the selected client.
• Description
  Optional description of the role.
• Client
  Client the role applies to; without a selection the role is cross-client.
• Workflow ID (required)
  Internal reference for approval processes. The field is pre-filled automatically with the role name and must be unique ("ParticipantId already in use"). Only letters, digits and underscore are allowed – no punctuation, spaces or hyphens (example: VAZ_Verantwortlicher). Normally the workflow ID should not be changed afterwards (only after consultation with Workflow).
• Default role
  Assigns the role to a system standard function: user, manager, HR admin, kiosk admin or system administrator. Each default role may only be assigned once per client.
• Badge
  Color style used to render the role as a badge in user interfaces (primary, secondary, success, danger, warning, light, dark). Vor lokalem Administrator verbergen Ist die Option aktiviert, wird die Rolle inklusive aller Zuordnungen bei lokalen Administratoren verborgen. Abgeleitet von Rolle (nur bei Mandanten-Rollen sichtbar) Zeigt die Vorlagen-Rolle, von der diese Mandanten-Rolle abgeleitet wurde (siehe unten).

Reiter Workflow Optionen

Achtung – Selbstgenehmigung an der Ebenengrenze: Befindet sich der Antragsteller (zugleich Rolleninhaber) in der höchsten erlaubten Suchebene, wird er trotz aktivierter Option "Antragsteller als Rolleninhaber für sich selbst unterdrücken" zum eigenen Vorgesetzten. Lösung: dieser Person direkt einen Vorgesetzten zuordnen (Rolle mit Kompetenzziel Person).

Reiter Aktionen

Ordnet den Rolleninhabern Aktionsberechtigungen zu. Über "Neue Aktionsberechtigung" wird die Aktion gewählt; die Checkbox "Vererbte Berechtigungen anzeigen" blendet zusätzlich Berechtigungen ein, die die Rolleninhaber aus anderen Quellen erhalten.

• Negativ Ja/Nein – schließt bei Ja von der Berechtigung aus statt sie zu erteilen.
• Gültig von – bis – Zeitraum der Berechtigung (leer = ab heute).
• Einsichtserlaubnis – wer darf über diese Aktion eingesehen werden: eigene Person, Orgeinheit, Orgeinheit + untergeordnete, Rollenkompetenz (Einsicht gemäß den Kompetenzzielen der Rolle), eigener Mandant, alle Mandanten.
• Berechtigung/Einsicht an untergeordnete Gruppen vererben – bei Ja erhalten bzw. betreffen auch die untergeordneten Gruppen die Berechtigung/Einsicht.

Die Liste zeigt je Berechtigung außerdem Modul, Anzahl der betroffenen User, Kompetenzziel und die Herkunft ("Zugeordnet von") und lässt sich filtern und sortieren.

Reiter Rolleninhaber

Zeigt die bestehenden Zuordnungen (mit erweiterter Suche nach Kompetenzziel, Rolleninhaber und Typ) und erlaubt neue über "Neuer Rolleninhaber":

• Kompetenzziel – wer darf eingesehen werden: Alle (nur mit Einsicht auf alle Mandanten wählbar), eine bestimmte Person, Gruppe oder ein Mandant. Zur Auswahl stehen nur Ziele, für die der Bearbeiter selbst Einsichtsberechtigung hat.
• Rolleninhaber – Person, Gruppe (alle Personen der Gruppe werden Rolleninhaber) oder Dynamische Rollenzuordnung. Bei dynamischer Zuordnung wird der Inhaber zur Laufzeit aus dem Kontext des Kompetenzziels bestimmt:
  • Eigene Orgeinheit – alle Personen derselben hierarchischen Gruppe (klassischer Fall "Rolle Kollege")
  • Eigene Orgeinheit + untergeordnete OE's
  • Eigener Mandant
  • Alle Mandanten (nur mit entsprechender Einsichtsberechtigung)
• Gültig von – bis – Gültigkeitszeitraum der Zuordnung.
• Reihung – 1 = primärer Rolleninhaber (z.B. Vorgesetzter), 2 = Stellvertreter, 3, 4, ... weitere Stellvertreter (siehe Stellvertreterregelung). Änderung über das Bearbeiten-Icon der Zeile.

Beim Bearbeiten einer bestehenden Zuordnung sind Reihung (bzw. der dynamische Typ) und Gültig-bis änderbar; Gültig-von nur, solange es in der Zukunft liegt. Beim Löschen einer aktuell gültigen Zuordnung wird diese mit sofortiger Wirkung beendet (Gültig-bis = jetzt); erst in der Zukunft beginnende Zuordnungen werden tatsächlich entfernt.

Reiter Abgeleitete Mandanten-Rollen

Eine Rolle kann als Vorlage für mandantenspezifische Rollen dienen. Über "Neue Mandantenrolle" wird pro Mandant eine abgeleitete Rolle erzeugt (Namensvorschlag: Vorlagenname + Mandant; pro Mandant nur eine Ableitung). Abgeleitete Rollen zeigen eine reduzierte Maske – im Wesentlichen den Aktionen-Reiter – und übernehmen die übrigen Eigenschaften von der Vorlage; das Feld "Abgeleitet von Rolle" verweist zurück. Die Liste zeigt alle Ableitungen mit Mandant und Sprung-Link.

Reiter Zugriffsrechte

Vergibt technische Zugriffsrechte (z.B. auf REST-Endpunkte) an die Rolleninhaber:

• Rollenspezifische Zugriffsrecht-Sets – Zuordnung vordefinierter Sets (mit Sprung-Link zur Set-Pflege).
• Rollenspezifische Zugriffsrechte – einzelne Rechte mit Selektor, Privileg und optionalem Verbieten.

Reiter Workflow Aufgaben

Bei lizenziertem Workflow-Modul erscheint zusätzlich der Reiter Workflow Aufgaben: Er zeigt die offenen Aufgaben-Zuordnungen der Rolle und ermöglicht deren Neubewertung (z.B. nach Änderungen an Rolleninhabern).

Suchen, Bearbeiten, Löschen

• Suche in der Übersicht nach Name, Beschreibung und Mandant; die Spalten Standardrolle und Workflow-ID sind ebenfalls filterbar. Das Editier-Icon öffnet die Detailansicht.
• Bearbeiten: Alle oben beschriebenen Felder und Reiter; die Workflow-ID im Standardfall nicht ändern.
• Löschen (nur Systemadministrator): Nach Sicherheitsabfrage wird die Rolle entfernt; bestehende Rolleninhaber-Zuordnungen und Kompetenzen werden dabei mit gestrigem Datum beendet (historisiert), nicht physisch gelöschtHide from local administrator
  When enabled, the role including all its assignments is hidden from local administrators.
• Derived from role (visible only for client roles)
  Shows the template role this client role was derived from (see below).

Workflow options tab

• Suppress requester as role holder for themselves
  Relevant when the requester is also a role holder (e.g. a manager): the request then goes to the deputy or hierarchically next role holder – prevents self-approval.
• Suppress requester's deputy as role holder
  Skips the requester's deputy during the search. Can only be enabled when the previous option is checked. Beware of departments with only two members (manager + deputy → the search finds nobody).
• Include hierarchical group when searching for role holders
  When set, the requester's hierarchical group is searched in addition to direct assignments. Example: Mr. Weiss, Mr. Wagner and Ms. Müller hold the role "manager" for group G01; Mr. Maier is directly assigned to Mr. Müller. Without the flag only Mr. Maier is found, with the flag also the role holders of group G01.
• Organization type
  Determines the organization structure searched for role holders: hierarchical organization, cost centers, project groups, loose groups or locations. Search direction and level settings are only available for the type "hierarchical organization"; loose groups have no hierarchy, so no hierarchical resolution takes place.
• Max. number of role holders for workflow
  A number greater than 0 limits the resolved role holders in a workflow (e.g. 2 → at most two possible managers, even if inheritance would yield more).
• Search direction (hierarchical organization only)
  None – search only within the own group/department; upwards – search in superordinate departments (useful for manager roles); downwards – search in subordinate departments (e.g. sick note by colleagues). Details in Roles.
• Number of levels to search for role holders (appears for upwards/downwards)
  Limits the search to the given number of levels.
• Highest level up to which may be searched (appears for upwards/downwards)
  Limits the search towards the top; no search beyond this level (top level = 1).

Caution – self-approval at the level boundary: If the requester (who is also a role holder) sits in the highest allowed search level, they become their own manager despite the enabled option "suppress requester as role holder for themselves". Solution: assign that person a manager directly (role with competence target person).

Actions tab

Assigns action permissions to the role holders. Choose the action via "New action permission"; the checkbox "Show inherited permissions" additionally displays permissions the role holders receive from other sources.

• Negative yes/no – if yes, excludes from the permission instead of granting it.
• Valid from – to – validity period of the permission (empty = from today).
• View permission – who may be viewed through this action: own person, org unit, org unit + subordinated, role competence (view according to the role's competence targets), own client, all clients.
• Inherit permission/view to subordinated groups – if yes, subordinated groups also receive or are covered by the permission/view.

The list additionally shows module, number of affected users, competence target and origin ("assigned from") per permission, and can be filtered and sorted.

Role holders tab

Shows the existing assignments (with extended search by competence target, role holder and type) and allows new ones via "New role holder":

• Competence target – who may be viewed: all (selectable only with all-clients view permission), a specific person, group or a client. Only targets the editor has view permission for are offered.
• Role holder – person, group (all persons of the group become role holders) or dynamic role assignment. With a dynamic assignment the holder is determined at runtime from the competence target's context:
  • Own org unit – all persons of the same hierarchical group (the classic "colleague" role)
  • Own org unit + subordinated org units
  • Own client
  • All clients (only with the corresponding view permission)
• Valid from – to – validity period of the assignment.
• Ranking – 1 = primary role holder (e.g. manager), 2 = deputy, 3, 4, ... further deputies (see deputy rules). Change via the row's edit icon.

When editing an existing assignment, ranking (or the dynamic type) and valid-to are changeable; valid-from only while it lies in the future. When deleting a currently valid assignment, it is ended immediately (valid-to = now); assignments starting in the future are actually removed.

Derived client roles tab

A role can serve as a template for client-specific roles. Via "New client role" a derived role is created per client (name proposal: template name + client; only one derivation per client). Derived roles show a reduced form – essentially the actions tab – and inherit the remaining properties from the template; the field "derived from role" points back. The list shows all derivations with client and jump link.

Access rights tab

Grants technical access rights (e.g. to REST endpoints) to the role holders:

• Role-specific access right sets – assignment of predefined sets (with jump link to set maintenance).
• Role-specific access rights – individual rights with selector, privilege and optional deny.

Workflow assignments tab

With a licensed workflow module, the additional tab workflow assignments appears: it shows the role's open task assignments and allows re-evaluating them (e.g. after changes to role holders).

Searching, editing, deleting

• Search in the overview by name, description and client; the columns default role and workflow ID are filterable as well. The edit icon opens the detail view.
• Editing: all fields and tabs described above; normally do not change the workflow ID.
• Deleting (system administrator only): after a confirmation prompt the role is removed; existing role holder assignments and competences are ended with yesterday's date (historicized), not physically deleted.