Wofür das Modul gedacht ist
Mitarbeiterverwaltung ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.
Mitarbeiter, Einladungen, Aktivstatus, Rollen und tenantweite Personaldaten organisieren. Im tenantweiten Kontext sorgt der Bereich dafür, dass wiederkehrende Entscheidungen, Stammdaten oder Übersichten nicht in Nebensysteme ausweichen müssen.
Mitarbeiterverwaltung ist als eigenständiger Produktbaustein gedacht. Gerade deshalb lohnt sich ein Blick darauf, wie der Bereich mit Rollen, Datenkontext und angrenzenden Modulen zusammenspielt.
Typische Einsatzfälle
Diese Situationen zeigen, wann der Bereich in einem sauberen Rollout oder im laufenden Betrieb konkret Mehrwert liefert.
Tenant sauber aufsetzen
Das Modul hilft dabei, organisatorische Regeln und Stammdaten an einer kontrollierten Stelle zu pflegen.
Verantwortung eingrenzen
Governance-Bereiche sollten nur wenige Personen pflegen, damit die Struktur stabil bleibt.
Rollouts belastbar machen
Eine klare Administrationsstruktur vereinfacht Onboarding, Rechtestruktur und spätere Produkterweiterungen.
Wie das Modul mit anderen Bereichen zusammenspielt
struct-i-vio ist als zusammenhängende Plattform gedacht. Diese Module liegen fachlich am nächsten bei diesem Bereich.
Stellenbezeichnungen
Stellenbezeichnungen ergänzt Mitarbeiterverwaltung, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsBerechtigungen
Berechtigungen ergänzt Mitarbeiterverwaltung, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsAnträge
Anträge ergänzt Mitarbeiterverwaltung, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsBerechtigungen und Sichtbarkeit
Die öffentliche Dokumentation beschreibt die Logik auf Produktniveau - nicht als technische Policy-Liste, sondern als Rollout-Leitfaden.
Best Practices
So bleibt der Bereich bei Einführung und Nutzung anschlussfähig an den restlichen Produktfluss.
Entwickler Info
Bedenkliches Modul: 5 von 15 Permissions sind UI-Hook-only enforced (nur React canAction-Check, kein API-Pre-Check, keine RLS-Policy). Plus 1 TRULY UNBOUND. Der Permission-Schutz hängt damit weitgehend an der Frontend-Schicht — wer den API direkt callt, umgeht ihn.
Entwickler-Info aufklappen (5)
⚠ KRITISCH5 UI-Hook-only Permissions ohne API/RLS-Backstop
view_employees, edit_employee, change_position_level, deactivate_employee und manage_job_positions werden NUR in pages/admin/employees.tsx via canAction geprüft. Die zugehörigen API-Endpoints (/api/employees, /api/admin/employees/[id]) haben keinen action-spezifischen Pre-Check, und es gibt keine RLS-Policy auf dim_employees mit diesen Permissions. Wer einen API-Client direkt aufruft (curl, andere Tools), umgeht die Permission. AUSNAHME bei manage_job_positions: zusätzlich aktiv in RLS auf job_positions — dort funktioniert der Schutz.
pages/admin/employees.tsx:187-195Endpoints ohne Pre-Check: /api/employees, /api/admin/employees/[id]
⚠ KRITISCHinvite_employee ist TRULY UNBOUND
Die Permission existiert in dim_modules, ist aber nirgends im Code, RPC, RLS oder View referenziert. Der tatsächliche Einladungs-Flow nutzt manage_invitations. Toggle wirkungslos — sollte aus dem Schema entfernt werden.
Self-Bypass für HR-Daten
employee_personal_details_select/insert/update haben jeweils OR-Klauseln: own employee_id ODER view_hr_details/edit_hr_details. Jeder User darf eigene HR-Daten lesen und pflegen, ohne die Permissions zu haben — pragmatischer Self-Service.
RLS: public.employee_personal_details :: epd_select / _insert / _update
Stage-1-Coupling: edit_rates → manage_job_positions (INSERT-Pfad)
Bekannte Layer-Mismatch-Coupling. API-Check fragt edit_rates, RLS-Insert-Policy auf job_positions verlangt manage_job_positions. Konflikt nur beim Anlegen NEUER Positionen — UPDATE-Pfad reicht edit_rates allein.
lib/permission-dependencies.ts
job_positions_select hat keine Permission-Klausel
Die SELECT-Policy auf job_positions ist tenant-only — jeder Mitarbeiter sieht alle Job-Positionen / Stundensätze. Nur Mutations sind durch manage_job_positions / edit_rates gegated. Pragmatisch — Job-Positionen sind nicht sensitiv — sollte aber bewusst entschieden sein.
RLS: public.job_positions :: job_positions_select