Wofür das Modul gedacht ist
Anträge ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.
Anträge genehmigen oder ablehnen. Im tenantweiten Kontext sorgt der Bereich dafür, dass wiederkehrende Entscheidungen, Stammdaten oder Übersichten nicht in Nebensysteme ausweichen müssen.
Anträge hängt fachlich an Abwesenheit. Dadurch ist für Nutzer sofort klar, in welchem größeren Ablauf das Modul seinen Platz hat.
Typische Einsatzfälle
Diese Situationen zeigen, wann der Bereich in einem sauberen Rollout oder im laufenden Betrieb konkret Mehrwert liefert.
Self-Service entlasten
Mitarbeitende können wiederkehrende Personalthemen direkt im passenden Ablauf bearbeiten.
Genehmigungspfade klären
Anträge, Korrekturen und Zielwerte bleiben transparent, sobald die zuständigen Rollen sauber gesetzt sind.
Kapazität planbar machen
Das Modul ist besonders wertvoll, wenn Abwesenheit, Soll-Werte und Stunden gemeinsam gedacht werden.
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.
Abwesenheit
Abwesenheit ergänzt Anträge, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsMeine Abwesenheit
Meine Abwesenheit ergänzt Anträge, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsMitarbeiterverwaltung
Mitarbeiterverwaltung ergänzt Anträge, 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
Vier Backdoors zur Antrags-Sicht via OR-Klauseln. Stage-1-Regel war fälschlich auf eine Phantom-Permission gerichtet — am 2026-05-07 korrigiert auf den richtigen action-key "view".
Entwickler-Info aufklappen (3)
⚠ KRITISCHDrei Backdoors zur Antrags-Sicht
employee_absences_select_with_permission gates über OR mit vier Klauseln: own employee_id (jeder sieht eigene Anträge), supervisor_id-Match aus employee_tenants (Supervisor sieht Direct Reports), view-Permission (HR-Rolle sieht alle), is_superadmin. Wer als Supervisor in employee_tenants eingetragen ist, sieht die Anträge seiner Direct Reports — auch ohne view-Permission. Auditierbar nur durch employee_tenants.supervisor_id-Inspection.
RLS: public.employee_absences :: employee_absences_select_with_permission
Backdoor: eigener pending-Antrag löschbar ohne delete-Permission
employee_absences_delete erlaubt DELETE wenn employee_id=self UND status=pending — unabhängig von der delete-Permission. User können also stets eigene noch-nicht-genehmigte Anträge zurückziehen. Pragmatisch sinnvoll, aber für Audit-Logs nicht offensichtlich.
RLS: public.employee_absences :: employee_absences_delete
⚠ KRITISCHPhantom-Permission-Bug behoben (2026-05-07)
lib/permission-dependencies.ts hatte bisher die Regel approve → view_all_requests, aber view_all_requests existiert in dim_modules NICHT. Die Regel produzierte unknown_dependency_target-Konflikte für jeden Tenant. Korrigiert auf "view" + reject-Regel ergänzt.
lib/permission-dependencies.ts