Rollenkonzept

Das Rollenkonzept in chronapp regelt, welche Benutzer:innen welche Funktionen sehen und ausführen dürfen. Rollen werden Benutzer:innen zugewiesen und können auf eine Organisationseinheit (OE) oder einen Company Code (CoCo) bezogen sein. Der Umfang des verfügbaren Rollenmodells richtet sich nach dem gebuchten Lizenzmodell.

Lizenzmodelle im Überblick

Merkmal	Basic	Pro	Ultimate
Anzahl Rollen	5 standardisierte Rollen	5 + 2 direkte Zuweisungsrollen	Frei definierbar
OE-Struktur	Tenant-übergreifende OE	Tenant-OE + direkte Zuweisungs-OEs	Vollständige OE-Struktur
Direkte Rollenzuweisung	Nein	Ja	Ja
Stellvertretung	Nein	Ja	Ja
CoCo-Struktur	Nein	Nein	Ja

Standard-Rollen (Basic Lizenz)

Bei der Basic Lizenz stehen fünf standardisierte Rollen zur Verfügung. Diese haben sich in der Praxis bewährt und ermöglichen eine einfache, kostengünstige Verwaltung ohne zusätzlichen Konfigurationsaufwand.

Es gibt genau eine Organisationseinheit im Tenant. Ein:e Vorgesetzte:r ist damit immer für den gesamten Tenant zuständig – eine feinere Gliederung nach Abteilungen oder Teams ist nicht vorgesehen.

Direkte Rollenzuweisungen und die Stellvertreterfunktion sind bei der Basic Lizenz nicht verfügbar.

Die fünf Standardrollen

Rolle	Beschreibung
Mitarbeitende	Standardrolle für alle Mitarbeitenden. Ermöglicht die Erfassung und Einsicht der eigenen Arbeitszeiten und Abwesenheiten.
Leitung Organisation	Vorgesetztenfunktion für die gesamte Organisation (= Tenant). Kann Abwesenheiten und Arbeitszeiten der unterstellten Mitarbeitenden einsehen und genehmigen.
Time Admin Organisation	Verwaltet Zeitdaten für die gesamte Organisation. Kann Korrekturen vornehmen und hat erweiterten Lesezugriff auf Zeiterfassungsdaten.
Projektadmin	Zuständig für die Verwaltung von Tätigkeiten und Projekten im gesamten Tenant.
Admin	Vollständige Administrationsberechtigung im Tenant. Kann Benutzer:innen, Rollen und Einstellungen verwalten.

Individuelle Direkt-Rollen (Pro Lizenz)

Die Pro Lizenz erweitert das Rollenmodell um zwei zusätzliche Rollen mit direkter Benutzerzuweisung sowie um die Stellvertreterfunktion.

Neben der Tenant-übergreifenden OE können weitere OEs ausschliesslich für die direkte Rollenzuweisung angelegt werden.

Alle verfügbaren Rollen (Pro)

Rolle	Direkte Zuweisung	Beschreibung
Mitarbeitende	Nein	Wie in der Basic Lizenz.
Leitung Organisation	Nein	Vorgesetztenfunktion für die gesamte Organisation.
Leitung (Direkte Zuweisung von Benutzer:innen)	Ja	Vorgesetztenfunktion, die gezielt einzelnen Benutzer:innen zugewiesen werden kann.
Time Admin Organisation	Nein	Zeitadministration für die gesamte Organisation.
Time Admin (Direkte Zuweisung von Benutzer:innen)	Ja	Zeitadministration, die gezielt einzelnen Benutzer:innen zugewiesen werden kann.
Projektadmin	Nein	Wie in der Basic Lizenz.
Admin	Nein	Wie in der Basic Lizenz.

Stellvertreterfunktion (ab Pro Lizenz)

Ab der Pro Lizenz steht die Stellvertreterfunktion zur Verfügung. Sie ermöglicht es, für jede Rollenzuweisung bis zu sechs Stellvertretende zu hinterlegen.

Stellvertretende übernehmen während der Abwesenheit der berechtigten Person (z.B. Ferien, Krankheit) deren Aufgaben und Berechtigungen im Rahmen der jeweiligen Rolle. Die Stellvertretung ist an die konkrete Rollenzuweisung geknüpft und muss pro Zuweisung separat konfiguriert werden.

Typische Anwendungsfälle:

Genehmigung von Abwesenheiten bei Abwesenheit der Führungskraft
Zeitkorrekturen durch eine Stellvertretung des Time Admins
Sicherstellung der Betriebskontinuität ohne Dauerberechtigungen vergeben zu müssen

Vollständige OE-Struktur und Rollenverwaltung (Ultimate Lizenz)

Die Ultimate Lizenz bietet die maximale Flexibilität:

Frei definierbare Rollen mit individuell konfigurierbaren Berechtigungen
Vollständige OE-Struktur mit beliebig tiefer Organisationshierarchie
CoCo-Struktur (Company Code) für Kostenstellen-basierte Berechtigungen
Vollständige Rollen- und Berechtigungsverwaltung ohne Einschränkungen

Berechtigungen und Rollen

Rollen in chronapp sind keine festen Berechtigungspakete, sondern werden aus einzelnen, granularen Berechtigungen ( Permissions) zusammengesetzt. Jede Rolle erhält eine definierte Menge von Berechtigungen, die zusammen ihren Funktionsumfang ergeben.

Aufbau einer Berechtigung

Berechtigungen folgen einem einheitlichen Namensschema:

[Modul].[Aktion].[Geltungsbereich]

Der Geltungsbereich (Scope) bestimmt, auf welche Daten sich die Berechtigung auswirkt. Nicht alle Berechtigungen existieren in allen Varianten – je nach Aktion sind nur bestimmte Scopes sinnvoll.

Geltungsbereiche im Detail

Am Beispiel der Berechtigung worktime.create (Arbeitszeit erfassen):

Berechtigung	Geltungsbereich	Bedeutung
`worktime.create`	Eigene Person (Basis)	Der/die eingeloggte Benutzer:in darf die eigene Arbeitszeit erfassen.
`worktime.create.self`	Selbst-Ausnahme	Steuert, ob die eigene Person eingeschlossen ist, wenn man aufgrund von `.ou`, `.coco` oder `.tenant` grundsätzlich Rechte hätte (siehe unten).
`worktime.create.ou`	Organisationseinheit	Darf Arbeitszeiten aller Personen in der zugewiesenen OE (und darunter) erfassen.
`worktime.create.coco`	Company Code	Darf Arbeitszeiten aller Personen im zugewiesenen Company Code erfassen.
`worktime.create.tenant`	Gesamter Tenant	Darf Arbeitszeiten aller Personen im Tenant erfassen.

Der Scope ou berücksichtigt die Tiefe der Organisationshierarchie: Bei der Zuweisung wird durch eine Zahl angegeben, für welche Tiefe der untergeordneten OEs die Berechtigung ebenfalls greift. Eine Tiefe von 1 bedeutet, dass die Berechtigung nur für die ausgewählte OE greift. Eine Tiefe von N + 1 heisst, dass die Berechtigungen für jede untergeordnete OE der Tiefe <= N gilt.

Die Sonderrolle von `.self`

Die Basis-Berechtigung ohne Scope (z.B. worktime.create) gilt immer für die eigene Person. Die .self-Variante hat eine andere, ergänzende Bedeutung: Sie greift dann, wenn jemand aufgrund einer übergeordneten Berechtigung (.ou, .coco, .tenant) auch sich selbst einschliessen würde – etwa eine Führungskraft, die ihrer eigenen OE angehört.

Mit .self lässt sich dieses Verhalten gezielt steuern:

.self gesetzt → die Person darf die Berechtigung auch auf sich selbst anwenden
.self nicht gesetzt → die eigene Person ist von der übergeordneten Berechtigung ausgeschlossen

Typisches Gegenbeispiel – Auszahlung: Eine Führungskraft hat payment.workflow.approve.ou, um Auszahlungen in der eigenen OE zu genehmigen. Damit sie sich nicht selbst Auszahlungen genehmigen kann, wird payment.workflow.approve.self bewusst nicht vergeben.

Company Code (CoCo)

Der Begriff CoCo steht für Company Code – einen Kostenrechnungskreis, der eine organisatorische Einheit für die Finanzbuchhaltung abbildet. In chronapp ermöglicht der CoCo-Scope eine bereichsübergreifende Berechtigung, die sich nicht an der OE-Hierarchie orientiert, sondern an der zugewiesenen Kostenrechnungseinheit.

Berechtigungskategorien

Die Berechtigungen sind nach Modulen und Aktionen strukturiert. Die wichtigsten Kategorien:

Kategorie	Beispiel-Berechtigungen
Arbeitszeiten	`worktime.read`, `worktime.create`, `worktime.update`, `worktime.delete`, `worktime.correction`
Abwesenheiten	`absence.read`, `absence.write`, `absence.workflow.approve`, `absence.workflow.confirm`
Salden	`balance.read`, `balance.write`, `balance.recalculate`
Rollen & Benutzer	`role.user.read`, `role.user.write`, `role.user.deputy.manage`, `role.user.impersonate`
Tätigkeiten	`activitytype.read`, `activitytype.write`
Benutzerprofile	`user.profile.read`, `user.profile.write`
Arbeitszeit-Workflow	`worktime.workflow.status.read`, `worktime.workflow.status.approve`, `worktime.workflow.status.confirm`

Jede dieser Kategorien steht in der Regel in den Varianten (kein Scope), .self, .ou, .coco und .tenant zur Verfügung.

Wie Berechtigungen Rollen ergeben

Jede Rolle bündelt eine festgelegte Kombination aus Berechtigungen und Scopes. Bei der Ultimate Lizenz können Berechtigungen und ihre Scopes frei kombiniert und eigenen Rollen zugewiesen werden – ohne Einschränkung auf vordefinierte Rollenpakete.

Beispiel – Berechtigung worktime.read nach Rolle:

Rolle	Zugewiesene Berechtigung	Effekt
Mitarbeitende	`worktime.read`	Sieht nur die eigene Zeiterfassung
Leitung Organisation	`worktime.read.ou`	Sieht alle Zeiterfassungen in der eigenen OE
Time Admin Organisation	`worktime.read.ou` + `worktime.correction.ou`	Sieht und korrigiert Zeiterfassungen in der OE
Admin	`worktime.read.tenant`	Sieht alle Zeiterfassungen im gesamten Tenant

Berechtigungen auf Endpunkt-Ebene

Jeder API-Endpunkt in chronapp ist mit mindestens einer konkreten Berechtigung abgesichert. Wo sinnvoll, werden mehrere Endpunkte durch dieselbe Berechtigung geschützt – zum Beispiel: Einzelne Absenz abfragen und Liste von Absenzen abfragen.

Beispiel – Endpunkte für Arbeitszeiten:

Endpunkt	Aktion	Erforderliche Berechtigung
`GET /worktimes`	Arbeitszeiten lesen	`worktime.read.[scope]`
`POST /worktimes`	Arbeitszeit erfassen	`worktime.create.[scope]`
`PUT /worktimes/{id}`	Arbeitszeit bearbeiten	`worktime.update.[scope]`
`DELETE /worktimes/{id}`	Arbeitszeit löschen	`worktime.delete.[scope]`
`PUT /worktimes/{id}/approve`	Arbeitszeit genehmigen	`worktime.workflow.status.approve.[scope]`

Diese Struktur stellt sicher, dass ein:e Benutzer:in zwar Daten lesen, aber nicht zwingend ändern darf – selbst wenn beide Aktionen dasselbe Modul betreffen. Der Scope schränkt dabei zusätzlich ein, wessen Daten betroffen sind.

Migration von timesaver nach chronapp

Bestehende Kunden, die von timesaver zu chronapp migriert wurden, wurden automatisch in das neue Rollenmodell überführt. Die folgende Tabelle zeigt die Zuordnung der alten timesaver-Rollen zu den neuen chronapp-Rollen:

timesaver (alt)	chronapp (neu)
Mitarbeiter	Mitarbeitende
Vorgesetzter	Leitung Organisation
Abwesenheitsverwaltung	Time Admin Organisation
Tätigkeitsverwaltung	Projektadmin
Mandant Verantwortlicher	Admin