|
|
## Hierarchisches Modell
|
|
## Hierarchisches Modell
|
|
|
|
|
|
|
|
Der Team-Manager verwendet für die Ermittlung der verwaltbaren User, für User in Leiterrollen, ein hierarchisches Modell in Kombination mit einem Attribut, das auf Rollen Basis gesetzt wird und welches entscheidet, ob ein User ein Teamleiter ist.
|
|
Der Team-Manager nutzt ein hierarchisches Modell zur Ermittlung verwaltbarer Nutzer. Grundlage ist ein Attribut auf Rollenebene, das festlegt, ob eine Rolle als Teamleitung gilt
|
|
|
|
|
|
|
|
**Ein Teamleiter darf User in der eigenen Abteilung und auch in tieferen Abteilungen verwalten (Abwesenheiten und u. a. ggf. Stellvertretungen konfigurieren). User ohne Leiterrolle können im Team-Manager jedoch trotzdem die Anwesenheit, Stellvertretung und weitere Daten anderer User einsehen, diese jedoch aber nicht editieren.**
|
|
**Teamleitungen** können Nutzer der eigenen sowie untergeordneten Abteilungen verwalten – etwa Abwesenheiten erfassen oder Stellvertretungen konfigurieren.
|
|
|
|
**Nutzer ohne Teamleitungsrolle** haben lediglich Leserechte und können Anwesenheit, Stellvertretungen und weitere Informationen anderer Nutzer einsehen, aber nicht bearbeiten
|
|
|
|
|
|
|
|
## Einrichtung des Teamleiterattributs
|
|
## Einrichtung des Teamleiterattributs
|
|
|
|
|
|
|
|
Das Attribut, welches kontrolliert<span dir="">, wer</span> ein Teamleiter ist, wird in der **teammanager-prod.yml** unter **absence-mgr-attribute-name** festgelegt (Siehe [Team-Manager Parameter](/open/teammanager/-/wikis/Konfiguration/Parameter)). **Dieses muss im enaio® Workflow-Editor unter demselben Namen als Rollenattribut hinzugefügt werden**
|
|
Das Attribut, das definiert, wer als Teamleitung gilt, wird in der **teammanager-prod.yml** über den Parameter **absence-mgr-attribute-name** konfiguriert (siehe [Team-Manager Parameter](/open/teammanager/-/wikis/Konfiguration/Parameter))
|
|
|
|
|
|
|
|
Hierfür öffnet man den **enaio® Workflow-Editor**
|
|
**Dieses Attribut muss im enaio® Workflow-Editor unter exakt demselben Namen als Rollenattribut angelegt werden.**
|
|
|
|
|
|
|
|
{width="820" height="466"}
|
|
## Schachtelung von Abteilungen aktivieren (optional)
|
|
|
|
|
|
|
|
Im Arbeitsbereich drückt man links auf den **Organisationsexplorer**
|
|
**Sehr empfehlenswert:** Die Schachtelung von Abteilungen im enaio® Workflow-Editor aktivieren.
|
|
|
|
Das erlaubt eine feinere Strukturierung von Teams und vereinfacht die gezielte Vergabe von Teamleiter-Rechten.
|
|
|
|
Ohne Schachtelung müssen Teamleiter unter Umständen sehr große Nutzergruppen verwalten.
|
|
|
|
|
|
|
|
{width="821" height="467"}
|
|
### Aktivierung:
|
|
|
|
|
|
|
|
Dann klickt man mit der rechten Maustaste unter den **Organisationsklassen** auf **Rolle**
|
|
1. Rechtsklick auf **Abteilung** unter **Organisationsklassen** → **Bearbeiten** wählen.
|
|
|
|
|
|
|
|
{width="821" height="463"}
|
|
|
|
|
|
|
|
|
|
Als Nächstes auf **Bearbeiten**
|
|
2. Im neuen Fenster auf den Tab **Hierarchie** wechseln.
|
|
|
|
|
|
|
|
{width="821" height="465"}
|
|
|
|
|
|
|
|
|
|
Mit einem Rechtsklick klickt man im Feld, wo die Attribute aufgelistet werden im Kontextmenü auf **neues Attribut**
|
|
3. In der Ansicht **Abteilung** auswählen und mit dem Pfeil nach rechts verschieben.
|
|
|
|
|
|
|
|
{width="821" height="469"}
|
|
|
|
|
|
|
|
|
|
Anschließend tippt man den Namen vom Attribut ein, den man in der **teammanager-prod.yml** unter **absence-mgr-attribute-name** angegeben hat und stellt sicher, dass der Typ auf **Bool** ist und der Standardwert nicht angekreuzt ist. Dann drückt man auf **OK** und danach auf **Apply**
|
|
4. Auf **Apply** klicken und die Organisation speichern.
|
|
|
|
|
|
|
|
{width="821" height="466"}
|
|
**Ab jetzt können Abteilungen ineinander verschachtelt werden.**
|
|
|
|
|
|
|
|
Als Letztes drückt man unter **Datei** auf **Speichern**. Das Attribut ist nun für alle Rollen registriert und für alle auf **false** gesetzt
|
|
|
|
|
|
|
|
|
|
## Schachtelung von Abteilungen aktivieren (Optional)
|
|
|
|
|
|
|
|
|
|
**Was optional aber sehr empfehlenswert ist, ist die Schachtelung von Abteilungen im enaio® Workflow-Editor zu erlauben**. Diese ermöglicht eine höhere Feingranularität in Bezug auf die Teamgröße und die Konfiguration von Teamleitern. Ohne Verschachtelung können Teamleiter mit größeren Gruppen von zu verwaltenden Usern konfrontiert werden.
|
|
|
|
|
|
|
|
|
|
Hierfür klickt man mit einem Rechtsklick unter den **Organisationsklassen** auf **Abteilung** und drückt auf **Bearbeiten**
|
|
|
|
|
|
|
|
|
|
{width="834" height="472"}
|
|
|
|
|
|
|
|
|
|
Im neu geöffneten Fenster wechselt man in den **Hierarchie-Tab**
|
|
|
|
|
|
|
|
|
|
{width="835" height="471"}
|
|
|
|
|
|
|
|
|
|
Dort sollte sich folgende Ansicht auffinden lassen. Hier klickt man auf **Abteilung** und drückt dann auf den nach rechts zeigenden Pfeil in der Mitte
|
|
|
|
|
|
|
|
|
|
{width="834" height="474"}
|
|
|
|
|
|
|
|
|
|
Zuletzt drückt man auf **Apply** und speichert die Organisation ab. **Nun sollte man in der Organisationsstruktur in der Lage sein, seine Abteilungen in Abteilungen zu verschachteln**
|
|
|
|
|
|
|
|
|
|
## Konfiguration von einer Beispielorganisation
|
|
## Konfiguration von einer Beispielorganisation
|
|
|
|
|
|
|
|
In einer Demo Organisation haben wir folgende **Organisationsstruktur** vorliegen
|
|
In einer Demo-Organisation liegt folgende **Organisationsstruktur** vor:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Wir möchten alle Rollen, die **Leitung** oder **Leiter** im Namen haben als Teamleiter Rolle designieren. Hierfür drücken wir unter **Organisationsklassen** auf **Rolle**
|
|
|
|
|
|
|
|
|
|
{width="867" height="438"}
|
|
Ziel: Alle Rollen mit **"Leitung"** oder **"Leiter"** im Namen sollen als Teamleiter gelten.
|
|
|
|
|
|
|
|
Dort sollten wir dann rechts im Fenster alle unsere definierten Rollen sehen. **Nun setzen wir das Team-Manager Attribut bei den Rollen, die wir als Leiter designieren möchten, auf wahr. Hierfür drückt man mit einem Rechtsklick auf eine der Zielrollen.**
|
|
### Vorgehen:
|
|
|
|
|
|
|
|
{width="873" height="441"}
|
|
1. Im **enaio® Workflow Editor** unter **Organisationsklassen** auf **Rolle** klicken:
|
|
|
|
|
|
|
|
Dann drückt man auf **Bearbeiten**
|
|
|
|
|
|
|
|
|
|
|
|
2. Rechts erscheinen alle definierten Rollen.
|
|
|
|
Jetzt das Teamleiter-Attribut bei den gewünschten Rollen auf **Ja** setzen:
|
|
|
|
|
|
|
|
Dort sollte man sein selbst definiertes Teamleiter Attribut vorfinden. Mit einem Doppelklick drückt man auf das **Nein** und setzt es dann auf **Ja**
|
|
Rechtsklick auf eine der Zielrollen:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zuletzt drückt man dann auf **OK**
|
|
3. **Bearbeiten** auswählen:
|
|
|
|
|
|
|
|
#### Alle User, die sich in MF_ENTWICKLUNG_LEITER befinden, dürfen nun alle User in der Entwicklungs-Abteilung verwalten (generell gesagt darf eine Leiterrolle alle Rollen in derselben Abteilung verwalten ausser die eigene, d.h. User in MF_ENTWICKLUNG_LEITER können sich nicht gegenseitig verwalten)
|
|
|
|
|
|
|
|
|
|
|
|
4. Im Attribut-Fenster das zuvor definierte **Teamleiter-Attribut** finden, doppelt auf **Nein** klicken und auf **Ja** setzen:
|
|
|
|
|
|
|
|
Das heißt das **VOGEL_MAX** jetzt bei **BAER_ADRIAN**, **BUCHER_ANDRIN**, **SCHMID_FLORIAN**, **STALDER_MIA** und **WEBER_NICOLE** die Abwesenheiten erfassen darf. Falls er bei sich selber die Stellvertreter konfigurieren darf, darf er dazu noch die Stellvertreter dieser User anpassen.
|
|
|
|
|
|
|
|
|
|
{width=739 height=408}
|
|
5. Mit **OK** bestätigen
|
|
|
|
|
|
|
|
**(Aufbau der Demo Organisation, Abteilungen in Blau und Rollen in Grün)**
|
|
Alle Nutzer in der Rolle **MF_ENTWICKLUNG_LEITER** dürfen sämtliche Rollen der Abteilung **Entwicklung** verwalten (**MF_ENTWICKLUNG**). Das umfasst das Erfassen von Abwesenheiten und falls erlaubt das Anpassen von Stellvertretungen. **Teamleiter können nicht gegenseitig Änderungen aneinander vornehmen (Ausnahme: absence-mgr-manages-own-role ist auf true gesetzt)**
|
|
|
|
|
|
|
|
#### Angenommen man geht nun gleich für MF_LEITUNG vor und designiert diese als Leiterrolle. Dann würde MF_LEITUNG alle tieferen Abteilungen + Rollen verwalten.
|
|
> **Beispiel:**
|
|
|
|
> **VOGEL_MAX** und **OSSERVICE** dürfen Abwesenheiten für **BAER_ADRIAN**, **BUCHER_ANDRIN**, **SCHMID_FLORIAN**, **STALDER_MIA** und **WEBER_NICOLE** verwalten. Wenn diese bei sich selbst Stellvertretungen bearbeiten dürfen, können sie das auch bei ihren untergeordneten Benutzern tun
|
|
|
|
|
|
|
|
{width=728 height=402}
|
|
|
|
|
|
|
|
|
|
(Alle Rollen die **MF_LEITUNG** verwalten darf in Orange)
|
|
#### Erweiterung auf höhere Leitungsebene
|
|
|
|
|
|
|
|
{width=735 height=406}
|
|
Wenn auch **MF_LEITUNG** als Teamleiterrolle definiert wird, erhält diese Rolle Zugriff auf alle tieferliegenden Abteilungen – inklusive deren Rollen.
|
|
|
|
|
|
|
|
(Rollen die **MF_ENTWICKLUNG_LEITER** und **MF_VERTRIEB_LEITUNG** verwalten darf in verschiedenen Farben)
|
|
|
|
|
|
|
|
|
|
## Bestandssysteme
|
|
## Bestandssysteme
|
|
|
|
|
|
|
|
Aus dem Grund<span dir="">, dass</span> nicht jeder seine Workflow-Organisation in **Bestandssystemen** ändern bzw. neu aufbauen kann, gibt es auch die Möglichkeit, die hierarchische Ermittlung von verwaltbaren Usergruppen nicht zu verwenden. Über **absence-admin-sys-roles** und **absence-admin-sys-groups** (genauer erläutert unter [Parameter](/open/teammanager/-/wikis/Konfiguration/Parameter)) kann man für bestimmte **Systemrollen** bzw. **Rechtegruppen** **Vollzugriff** auf die Abwesenheitsverwaltung erteilen.
|
|
Für Systeme, bei denen keine Umstrukturierung der Workflow-Organisation möglich oder sinnvoll ist, kann das hierarchische Modell deaktiviert werden. Stattdessen lassen sich konkrete Systemrollen oder Rechtegruppen über die Konfigurationsparameter **absence-admin-sys-roles** und **absence-admin-sys-groups** mit vollen Rechten ausstatten. **Benutzer welche mit den konfigurierten enaio®-Systemrollen/enaio®-Systemrechtegruppen ausgestattet sind, können die Abwesenheiten aller Benutzer in der Workflow-Organisation verwalten** |
|
|
|
|
|
|
|
**Dies ermöglicht zwar nicht die gleiche feingranulare Steuerung wie die hierarchische Ermittlung, erleichtert jedoch die Kompatibilität mit Bestandssystemen** |
|
|
|
\ No newline at end of file |
|
|
