Compare commits

171 Commits

Author SHA1 Message Date
96c94642ba Datumsfelder lassen sich wieder tippen
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m50s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m13s
In den Berichten hing jedes Datumsfeld unmittelbar an der Adresszeile: eine
Aenderung hiess router.push, also neu laden und neu rendern. Ein
<input type="date"> meldet beim Tippen der Jahreszahl aber viermal -- 0002,
0020, 0202, 2026 -- und die ersten drei loesten je eine Navigation aus, die das
Feld auf den Stand aus der Adresse zuruecksetzte. Mitten im Tippen. Mit dem
Kalender ging es, weil der in einem Zug ein fertiges Datum setzt; das war der
Hinweis darauf, wo es klemmt.

DateField haelt den Tippstand jetzt bei sich und meldet nur, was eine Aussage
ist: ein vollstaendiges Datum mit vierstelliger Jahreszahl ab 1000, oder das
Leeren des Feldes. Beim Verlassen wird nachgereicht, was liegengeblieben ist.
Der Stichtag im Organigramm ist ein blankes input und benutzt dieselbe Regel
ueber istMeldbaresDatum -- zwei Fassungen davon liefen hier erfahrungsgemaess
auseinander.

Der Abgleich mit dem Wert von aussen laeuft waehrend des Renderns, nicht in
einem Effekt: der liefe erst nach dem Zeichnen, das Feld zeigte also fuer einen
Bildaufbau den alten Stand -- und die Regel gegen setState im Effekt verbietet
ihn aus genau diesem Grund.

Die Felder in den Panels bleiben, wie sie sind: dort ist der Zustand lokal, es
gibt keine Navigation und damit auch kein Zuruecksetzen.
2026-09-29 21:39:35 +02:00
d9966c9623 Personalnummer im gedruckten Organigramm, wahlweise
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m23s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m13s
Von Max gewuenscht, ausdruecklich mit Auswahl oben. Ein Haekchen in "Was soll
aufs Papier?" stellt die Nummer hinter den Namen -- nicht in eine eigene Zeile:
auf einem Blatt mit zweihundert Kaesten kostet jede zusaetzliche Zeile
Massstab, und der entscheidet darueber, ob das Blatt noch lesbar ist.

Angeboten auf jeder Tiefe, nicht nur bei "mit Personen". Die Leitung einer
Einheit steht auch auf den Blaettern, die sonst keine Namen fuehren; ein
Haekchen, das dort fehlte, saehe aus, als gaebe es dort keine Namen.

Als Kontext statt als Eigenschaft durch den Baum: die Angabe betrifft eine
einzige Zeile ganz unten, muesste aber sonst durch vier Signaturen der
Seitenerzeugung durchgereicht werden. Und die Kennung der Messung traegt den
Schalter mit -- die Zeilen werden breiter, also muss der Massstab neu gemessen
werden, sonst liefe das Blatt ueber den Rand.
2026-09-29 21:03:50 +02:00
0039ce5069 Headcount heisst ueberall dasselbe
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m36s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m12s
"Headcount" stand auf der Uebersicht fuer die Aktiven und im Bericht fuer eine
andere Zahl -- 785 gegen 788, dasselbe Wort fuer Verschiedenes (N.02). Max hat
die Begriffe festgelegt: Headcount Aktiv fuer die Aktiven, Headcount Aktives
Dienstverhaeltnis fuer Aktive plus Langzeitabwesende.

Die beiden Kacheln auf der Uebersicht tragen jetzt genau diese Namen. Beide
Zahlen gab es dort schon, nur hiess die eine "Aktives Dienstverhaeltnis" und
die andere "Aktive Mitarbeiter:innen (HC)".

Im Bericht ginge ein fester Name nicht: die Kennzahl zaehlt, was gerade
ausgewaehlt ist, auch Geplante oder Ausgetretene. Trifft die Auswahl eine der
beiden Groessen, steht ihr Name in der Ueberschrift; sonst steht dabei, welche
Status gezaehlt wurden -- mit den Anzeigenamen, also "Langzeitabwesenheit" und
nicht "Karenz".
2026-09-29 20:36:22 +02:00
38f8c99968 Eine Befoerderung benennt die Planstelle um
Some checks failed
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
CI / Lint, Typen, Tests, Build (push) Has been cancelled
Bisher schrieb promote_employee den neuen Titel nach employees.job_title -- und
nur dorthin. Gesehen hat ihn niemand: Akte, Organigramm und die Exporte zeigen
alle die Taetigkeit der Planstelle. Haltbar war er auch nicht, denn
hire_employee, transfer_employee und change_employee_data setzen dieselbe
Spalte aus der Planstelle; die naechste Adressaenderung ueberschrieb ihn wieder.

Gemeldet von Lara und im Testprotokoll als H.10. Max hat entschieden: die
Befoerderung benennt die Planstelle um.

Umbenannt wird die Stelle, auf der die Person danach sitzt -- die Zielstelle,
sonst die bisherige. Im Formular ist das ohne Ueberraschung, weil es beim
Waehlen einer Zielplanstelle deren Taetigkeit als Vorschlag eintraegt: wer
nichts aendert, benennt auch nichts um. Und umbenannt wird nicht der
Katalogeintrag, sondern die Planstelle zeigt auf einen anderen -- den Eintrag
selbst umzubenennen traefe jede Planstelle mit derselben Taetigkeit.

Die Regel "gleiche Taetigkeit, ein Katalogeintrag" stand nur in
create_position und wandert nach job_fuer_titel(); zwei Fassungen derselben
Regel laufen hier erfahrungsgemaess auseinander. Die Nummernvergabe nimmt dabei
die erste freie statt count(*) + 1 -- gezaehlt wurde bisher, und das vergibt
eine belegte Nummer, sobald ein Eintrag geloescht wurde oder Codes aus einer
fremden Quelle danebenstehen, wie bei der Uebernahme der Manner-Daten.

Der Nachtlauf tut dasselbe, sonst benennt eine datierte Befoerderung am
Stichtag nichts um. Der Rauchtest prueft beide Wege und dass der alte
Katalogeintrag stehen bleibt.
2026-09-29 20:29:56 +02:00
fe858c6c24 YTD heisst bis heute, nicht bis zum Jahresende
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m29s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m6s
Die Kacheln "Eintritte/Austritte (YTD)" zaehlten bis zum 31.12. und damit auch,
was erst bevorsteht: ein fuer den 01.11. erfasster Austritt stand schon im
September als geschehen da. Die Kachel sagte 2, tatsaechlich war es 1.

Der Kommentar an der Kachel nannte die Absicht seit jeher richtig -- "seit
Jahresbeginn bis heute, nicht das ganze Kalenderjahr" --, nur stand darunter
yearEnd. Was kommt, steht ohnehin in "Anstehend" daneben; die Kachel soll
sagen, was war.

Der Verweis auf den Bericht traegt denselben Zeitraum, sonst zeigte der Bericht
eine andere Zahl als die Kachel, ueber die man ihn geoeffnet hat. Und die
Variable heisst jetzt ytdBis statt yearEnd -- ein Name, der "Jahresende" sagt
und "heute" bedeutet, waere die naechste Fundstelle gewesen.
2026-09-29 20:05:55 +02:00
cf5ed5c6c6 Vier Befunde, die still falsche Ergebnisse lieferten
Some checks failed
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
CI / Lint, Typen, Tests, Build (push) Successful in 11m17s
C.08 -- die Suche mit Bindestrich fand nichts. Das Feld wird per translate an
"-/:.," in Leerzeichen zerlegt, die Eingabe aber nicht: "Mueller-Weiss" erzeugte
das Muster mueller-weiss%, waehrend im Heuhaufen "mueller weiss" stand. Ohne
Bindestrich fand man dieselbe Person. Die Trennzeichen stehen jetzt einmal in
lib/employee-search.ts und werden von beiden Seiten des Vergleichs benutzt.

C.09 -- der Einheitenfilter verlor jede Person mit vorgemerktem Austritt.
"Laufend" war valid_to is null, aber terminate_employee setzt das Ende schon
beim Erfassen, Monate vor dem Tag. Jetzt zaehlt auch, was noch laeuft
(valid_to > heute). Bewusst ohne valid_from <= heute: ein geplanter Eintritt
gehoert in die Liste, sonst fiele er aus dem Filter, obwohl der Status
"Geplant" ihn ausdruecklich fuehrt.

E.07 -- nur die Kostenstelle zu aendern war unmoeglich. update_position weist
einen Aufruf ohne Aenderung ab, und die Umkontierung lief erst bei dessen
Erfolg. Sie wird jetzt uebersprungen, wenn sich an den Stammangaben nichts
geaendert hat.

H.06 -- jedes Speichern erzeugte zusaetzlich "Wochenstunden 30.0 -> 30". Der
Vergleich laeuft ueber Text, die Spalte ist numeric(4,1), und das Formular
schickt 30. Der Kommentar an der Zeile nannte die Absicht richtig, nur reicht
::numeric dafuer nicht -- es muss auf die Genauigkeit der Spalte gehen.
2026-09-29 19:47:48 +02:00
a0b9f6dc80 Anker aus der laufenden Definition, und ein Test, der sich selbst durchwinkt
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m33s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m15s
Zwei Fehler aus dem ersten Lauf des Rauchtests, beide von mir.

Der Anker fuer transfer_employee stammte aus 20260727120200 und fand nichts:
die Funktion ist seither dynamisch gepatcht worden, die Belegungsabfrage ist
zweizeilig und beruecksichtigt den Stichtag. Dieselbe Falle wie immer, nur
diesmal nicht im Rumpf einer Funktion, sondern im Anker auf sie -- fuer
hire_employee und rehire_employee stimmten die Anker, weil sie aus der zuletzt
erzeugten Fassung kamen. Die Migration war nie angewendet (sie bricht als
Ganzes ab), deshalb die Datei korrigiert statt eine neue geschrieben.

Und der Rauchtest hat sich an einer Stelle selbst durchgewunken: das `raise`
fuer den Fehlschlag stand innerhalb des Blocks mit exception-Zweig, wurde also
vom eigenen Handler gefangen -- und weil seine Meldung das Wort "vorgemerkte"
enthielt, bestand die Pruefung auf die erwartete Fehlermeldung. Der Schritt
galt als bestanden, obwohl die Migration gar nicht angewendet war. Jetzt merkt
sich der Block nur, ob es ging, und ausgewertet wird danach.
2026-09-29 19:24:58 +02:00
194b6d8916 Rauchtest: der Lebenszyklus, einmal wirklich ausgefuehrt -- und die fuenfte Fundstelle
Some checks failed
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
CI / Lint, Typen, Tests, Build (push) Has been cancelled
rehire_employee war seit dem 17.09. bei jedem Aufruf kaputt, und keine Pruefung
konnte das bemerken: die Selbstpruefungen der Migrationen lesen den Text der
Funktionen, die Unit-Tests laufen ohne Datenbank, und die Integrationstests
haben keinen Bestand, gegen den sie liefen. db/tests/rauchtest.sql schliesst
die Luecke -- es ruft die Funktionen auf, gegen die echte Datenbank, in der
Reihenfolge des Lebenszyklus: anlegen, versetzen, befoerdern, vormerken,
austreten, wiedereintreten.

Zwei Eigenschaften, ohne die es gefaehrlich waere. Es laeuft als
Anwendungsrolle statt als Superuser -- sonst bewiese es nur, dass die
Funktionen fuer niemanden gehen, der sie benutzt. Und es rollt am Ende zurueck,
mit einer Zaehlung danach, die das belegt: beim Test vom 29.09. sind reale
Personen auf Testplanstellen umgezogen und dort geblieben.

Beim Schreiben fiel die fuenfte Stelle mit dem Paar aus Schliessen und
Einfuegen auf: terminate_employee. Wer heute eingestellt und heute wieder
ausgetragen wird -- ohne den Grund "No Show" --, lief in chk_assignment_range.
Die No-Show-Haelfte derselben Funktion macht es laengst richtig und erklaert
auch, warum; es galt nur fuer genau einen Austrittsgrund.
2026-09-29 19:17:33 +02:00
89ba34c901 Vorgemerkte Planstellen, Stichtag fuer Einheiten, Kuendigungsschutz und Elternteilzeit
Some checks failed
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
CI / Lint, Typen, Tests, Build (push) Has been cancelled
F.24 -- eine Planstelle, auf die eine Versetzung vorgemerkt ist, galt als frei.
Die Vormerkung steht in pending_org_changes, "besetzt?" wurde allein an
position_assignments gefragt. Auffallen wuerde es erst in der Nacht des
Wirksamkeitstages: dort legt der Nachtlauf die zweite Besetzung an und laeuft in
den Teilindex, der genau eine laufende Besetzung je Planstelle zulaesst. Er
arbeitet in einer Transaktion ueber alle faelligen Vorgaenge -- eine einzige
solche Buchung haette ihn vollstaendig zum Stehen gebracht, auch fuer alle
anderen. Neue Auskunft planstelle_vorgemerkt, abgefragt in hire_employee,
rehire_employee, transfer_employee und promote_employee, mit Datum in der
Meldung. Die eigene Vormerkung zaehlt nicht als Hindernis.

D.06 -- die Struktursicht zeigte Einheiten, die es am gewaehlten Stichtag noch
nicht gab: org_units wurde ungefiltert gelesen, waehrend Planstellen und
Besetzungen daneben auf den Stichtag eingeschraenkt waren. Die Druckansicht
filterte schon immer richtig; jetzt tun es alle drei Stellen.

H.09 -- der Kuendigungsschutz stand in der Akte nur als "bis TT.MM.JJJJ",
obwohl Personenkreis, Beginn, Ende und die ganze Begunstigung erfasst werden.
Der Personenkreis ist die eigentliche Auskunft. Die Behinderung bekommt eine
eigene Zeile: sie fuehrt oft zu Kuendigungsschutz, ist aber ein eigener
Bescheid.

Elternteilzeit und Wiedereingliederungsteilzeit sind jetzt auch bei der
Stundenaenderung waehlbar. Sie standen nur bei der Rueckkehr aus einer
Abwesenheit, mit der Begruendung, dass sie typischerweise dann beginnen --
typischerweise ist aber nicht immer. Die Ueberschneidung der beiden Listen ist
damit gewollt; der Test prueft nicht mehr auf Partition, sondern darauf, dass
keine Teilzeit an keinem der beiden Wege haengt.
2026-09-29 19:10:31 +02:00
990ebdbc84 Versetzung und Befoerderung am Tag, an dem die Besetzung begann
Some checks failed
CI / Lint, Typen, Tests, Build (push) Successful in 11m24s
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
Wer heute schon einmal versetzt wurde, liess sich heute nicht noch einmal
versetzen oder befoerdern: die laufende Besetzung beginnt dann heute, und der
Code schliesst sie auf denselben Tag. chk_assignment_range verlangt aber
valid_to > valid_from -- ein Intervall von null Tagen ist verboten, und der
Vorgang brach mit der rohen Datenbankmeldung ab.

Das Verbot ist richtig, und der Fall ist im Haus schon einmal entschieden
worden: terminate_employee loescht die Besetzung beim Grund "No Show", statt
sie auf [Eintritt, Eintritt) zu schliessen -- niemand hatte sie je inne.
Dieselbe Begruendung gilt hier. Die zweite Versetzung am selben Tag
abzuweisen waere genau der haeufigste Fall gewesen: jemand hat die falsche
Planstelle erwischt und will es sofort richtigstellen. Beide Ereignisse
bleiben in der Historie stehen.

Vier Stellen mit demselben Paar aus Schliessen und Einfuegen: transfer_employee,
promote_employee und im Nachtlauf die Zweige transfer und promotion. Alle vier
aus der laufenden Definition gelesen und an einem Anker ergaenzt; die
Selbstpruefung zaehlt die beiden Stellen im Nachtlauf, statt nur ihr
Vorhandensein zu pruefen -- der Zweig transfer ist dort schon einmal spurlos
verschwunden.
2026-09-29 18:57:56 +02:00
be9ca4758f Wiedereintritt wieder moeglich, und die Panels lesen die Akte neu
Some checks failed
CI / Lint, Typen, Tests, Build (push) Successful in 11m36s
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
Zwei Befunde aus dem Test vom 29.09., beide Klasse A.

K.01 -- rehire_employee scheitert bei jedem Aufruf: der case-Ausdruck fuer den
Status liefert text, die Spalte ist ein Aufzaehlungstyp. Genau das wurde am
10.08. schon einmal behoben. Vier spaetere Migrationen haben die Funktion neu
erzeugt und den Zusatz nicht mitgenommen -- zwei davon aus einer aelteren
Datei, zwei aus der laufenden Definition. Daraus die Lehre, die vorher nicht
dastand: aus dem laufenden Stand zu erzeugen schuetzt davor, Verhalten zu
verlieren, nicht davor, einen bereits vorhandenen Fehler mitzunehmen. Die
Selbstpruefung benennt deshalb jetzt das Erwartete und nicht nur das Neue.

H.05 -- "Daten aendern" schrieb veraltete Werte zurueck. Die Panels bleiben
eingebunden, damit ihr Ein- und Ausfahren laufen kann, belegen ihre Felder aber
mit useState(employee.…) vor -- und das laeuft nur beim ersten Aufbau. Nach
einer Befoerderung brachte router.refresh() die frische Akte herein, der
Zustand im Panel blieb der von vorhin, und beim naechsten Speichern ging er als
Ganzes an change_employee_data: der eben gesetzte Hay-Grade stand wieder auf
dem alten Wert. Jedes Panel bekommt jetzt einen key aus employees.updated_at,
der sich bei jeder Aenderung an der Zeile bewegt und sonst nie. Der
Wiedereintritts-Assistent daneben macht es seit jeher so.
2026-09-29 18:42:30 +02:00
3664b9a435 Neuer Slogan, und Hay-Grades stehen als Leiter statt nach Haeufigkeit
Some checks failed
CI / Lint, Typen, Tests, Build (push) Successful in 11m48s
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
Auf der Anmeldeseite steht jetzt "Alles im Blick. Alles Manner." statt des
bisherigen Satzes.

Die Berichte sortieren Gruppen nach der Kennzahl, gross zuerst. Bei Bereich
oder Standort ist das die Antwort auf die Frage, die der Bericht stellt. Bei
einer Leiter ist es keine: HG09 vor HG10 ist die Reihenfolge, in der die Werte
sind, und nach Haeufigkeit umgestellt liest sie sich als Zufall.

Die Sonderbehandlung, die es fuer Wochentage schon gab, ist dafuer zu einer
Liste "Dimensionen mit eigener Reihenfolge" verallgemeinert -- Wochentage und
Hay-Grades stehen darin, und die naechste Leiter ist ein Eintrag statt einer
dritten Verzweigung. Gilt damit auch fuer die Aufschluesselung innerhalb einer
Gruppe und fuer die Spalten im Berichtsexport, die dieselbe Funktion nutzen.

Der Generic Grade steht vor HG09: er ist keine Stufe, sondern ihr Fehlen, und
vor der niedrigsten faellt das am wenigsten als Aussage auf.
2026-09-29 18:26:38 +02:00
2eda038c2e Kontierung auch bei besetzten Planstellen -- aus dem Organigramm heraus
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m47s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m6s
Die Kostenstelle liess sich an genau einer Stelle aendern: auf der Seite
Positionen, ueber die Karte einer Vakanz. Diese Seite zeigt aber nur unbesetzte
und kuenftige Planstellen. Bei einer besetzten war die Kontierung damit nirgends
zu erreichen -- im Bestand betrifft das 784 von 788, und dasselbe galt fuer ihre
Taetigkeit.

Die Angaben zu einer Einheit fuehren jetzt ihre Planstellen auf, besetzte
eingeschlossen, mit Inhaber:in und Kostenstelle. Ein Klick oeffnet denselben
Dialog wie auf Positionen, kein zweiter daneben. Was sich aendern laesst,
entscheidet weiterhin die Datenbank: bei einer besetzten Stelle bleiben Einheit
und Gueltigkeitsende gesperrt, weil ein Abteilungswechsel ueber eine Versetzung
gehoert und nicht ueber die Stelle.

Geladen wird erst beim Oeffnen und nur fuer diese eine Einheit. Alle 788
Planstellen in jede Zeichnung des Organigramms zu legen hiesse, fuer achtzig
Einheiten zu laden, was man fuer eine braucht.

EditPositionModal verlangt dafuer nicht mehr eine OpenPositionResolved, sondern
nur noch die Felder, die er tatsaechlich liest. Die alte Signatur war der
Grund, warum er nur dort aufzumachen war, wo unbesetzte Stellen entstehen.
2026-09-28 21:52:01 +02:00
ab50c21b8a Klick auf eine Einheit zeigt ihre Angaben
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m56s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m7s
Die naheliegendste Geste in dieser Ansicht war ohne Wirkung: eine Karte im
Organigramm liess sich anklicken und antwortete nicht. Jetzt oeffnet sie eine
Leiste mit dem, was an der Einheit steht -- Orgnummer, Art, die Kette nach
oben, Gueltigkeit, Leitung, Belegschaft, unbesetzte Planstellen, die direkt
untergeordneten Einheiten und die Zahl der Personen im ganzen Teilbaum. Dazu
dieselben zwei Handlungen wie auf der Karte, nur beschriftet statt als Symbol.

Alles daraus stammt aus den Daten, die die Struktursicht ohnehin geladen hat.
Kein zusaetzlicher Gang zur Datenbank und damit auch keine zweite Wahrheit --
was die Leiste zeigt, ist dasselbe, woraus der Baum daneben gezeichnet ist.

Die Liste klickt sich genauso: beide Ansichten kommen aus einem Baum, und eine
Handlung, die es nur in einer von beiden gibt, findet man in der anderen nie.

org_units liefert dafuer zusaetzlich valid_from und valid_to, aber nur an die
Struktursicht. Der Druck kommt ohne sie aus; auf OrgUnitNode stehen sie deshalb
als optionale Felder und nicht als zwei weitere Spalten, die ueberall
mitgeschleppt werden.
2026-09-28 21:27:36 +02:00
a3dde61ec1 Eine leere Organisationseinheit wieder entfernen
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m29s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m10s
Der Papierkorb neben dem Plus, im Organigramm wie in der Liste, und nur dort,
wo nichts darunter haengt. Ein Knopf, der beim Klick eine Absage erteilt, ist
schlechter als kein Knopf -- die Datenbank prueft es trotzdem, denn sie sieht
auch geschlossene Planstellen, die im Baum gar nicht gezeichnet sind.

Abgewiesen wird mit Grund: untergeordnete Einheiten, Planstellen (geschlossene
zaehlen mit), Kostenstellen, die darauf verweisen, und die Wurzel selbst.

Geloescht und nicht geschlossen, und das ist eine bewusste Einschraenkung.
delete_position macht seit dem OM-Umbau den Unterschied vor: besetzt gewesen →
valid_to, nie besetzt gewesen → weg. Fuer Einheiten laesst sich davon heute nur
die zweite Haelfte umsetzen, weil ein valid_to an einer Einheit zwar
eingetragen, aber nirgends gelesen wuerde -- weder Organigramm noch
orgMapsAbfragen, Berichte, Druck oder die Auswahl beim Anlegen einer Planstelle
schraenken org_units auf den Stichtag ein. Die geschlossene Einheit staende
ueberall weiter da, nur mit einem Datum, das niemand sieht. Das Schliessen zum
Stichtag kommt, wenn org_units gegen den Stichtag gelesen wird -- dieselbe
Arbeit, die auch das Verschieben braucht.
2026-09-28 16:51:26 +02:00
a6b6a7d67c Eine Organisationseinheit aus dem Organigramm heraus anlegen
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m30s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m22s
Bisher gab es dafuer nur den Import. Jetzt sitzt auf jeder Einheit im
Organigramm -- in der Grafik wie in der Liste -- ein Plus, das eine
untergeordnete Einheit anlegt, wahlweise gleich mit Leitungsplanstelle.

Bewusst nur dieser eine Fall. Umbenennen, verschieben und schliessen fehlen
nicht aus Zeitmangel: org_units.parent_id traegt kein Datum, ein Verschieben
aenderte damit auch jede Auswertung auf einen vergangenen Stichtag, und der
fruehere Stand waere danach nirgends mehr ablesbar. Anlegen stellt diese Frage
nicht, weil vorher nichts da war -- und es kann dabei auch kein Kreis
entstehen, was hier mehr wiegt als es klingt: die rekursive Abfrage in
om_reporting_lines hat weder Tiefenbegrenzung noch Kreiserkennung.

Die Leitungsplanstelle entsteht ueber create_position statt durch eine zweite
Fassung derselben Logik -- dort haengen Jobkatalog, Nummernvergabe und die
Pruefung "je Einheit genau eine Leitung".

Die Orgnummer wird eingetragen, nicht vergeben. Vorgeschlagen wird die naechste
freie Nummer der bestehenden Reihe, und nur dann, wenn sich im Bestand genau
eine Systematik ablesen laesst -- eine plausibel aussehende, aber erfundene
Nummer prueft niemand nach.

Das Datum kommt nicht aus dem Stichtag der Ansicht. Wer sich die Struktur zum
letzten Jahresende ansieht und auf Plus drueckt, will in aller Regel eine
Einheit von heute anlegen.
2026-09-28 16:28:33 +02:00
8b7e32f14a Hay-Grade auch in "Daten aendern"
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m35s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m10s
Die Befoerderung konnte ihn schon setzen, "Daten aendern" nicht -- weder das
Formular noch change_employee_data kannten das Feld. Damit war eine Einstufung
nur ueber den Weg "Befoerderung" zu aendern, und eine Richtigstellung ("da
stand von Anfang an die falsche Stufe") ist keine Befoerderung: sie soll keine
Planstelle wechseln und kein Ereignis in der Historie hinterlassen.

Das Feld gehoert zur Gruppe contract und ist damit datiert -- eine Umstufung
gilt ab einem Tag. Es kann also in pending_org_changes landen, und deshalb
steht es auch im Nachtlauf. Genau diese zweite Stelle ist hier schon einmal
vergessen worden: die Gruppe role fehlte dort monatelang, und eine datierte
Aenderung wurde als applied vermerkt, ohne etwas zu tun. Drittens
app_feld_karte, sonst waere der Eintrag in der Historie nicht richtigstellbar.

Alle drei Funktionen werden aus der laufenden Definition gelesen und an genau
einem Anker ergaenzt, nicht aus einer Datei kopiert.

Der Test zur Feldkarte liest jetzt alle Migrationen statt einer bestimmten. Der
feste Dateiname darin trug den Vermerk "die zuletzt gueltige Fassung" und war
schon zwei Migrationen spaeter falsch -- und ein Teil der Feldkarte kommt
inzwischen ohnehin aus einer Punktaenderung statt aus einer vollstaendigen
Fassung.
2026-09-28 15:06:58 +02:00
771020af72 LOLYO-Export: typografische Zeichen auf ASCII
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m21s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m10s
Der Gedankenstrich kam im Zielsystem als "–" an -- seine UTF-8-Bytes, gelesen
als Windows-1252. Nachgemessen hat die Vorlage des Anbieters dieselbe Kodierung
wie unsere Datei: UTF-8 ohne BOM, zu sehen an dem "bestätigt" in ihrer
Kopfzeile. Die Ursache liegt also nicht in dem, was wir schreiben, und solange
sie nicht geklaert ist, geht der Weg ueber das Zeichen selbst: ein Bindestrich
sagt dasselbe und ist in beiden Kodierungen dasselbe Byte.

Gilt fuer jede Zelle aus den Daten, nicht nur fuer die Position -- aufgefallen
ist es dort, weil die Taetigkeiten einen Gedankenstrich fuehren, aber dieselben
Zeichen stehen auch in Namen und Titeln.

Zwei Ausnahmen: Umlaute bleiben, weil "Baeckerei" ein Problem verstecken wuerde,
das dann auch Namen betraefe. Und das Passwort bleibt Zeichen fuer Zeichen, wie
es ist -- ein ersetztes Zeichen faellt niemandem auf, es gibt dann nur ein
Konto, in das niemand hineinkommt.
2026-09-28 14:05:41 +02:00
8ac4df17c1 Position im Export: die Taetigkeit der Planstelle, nicht die Spalte an der Person
Some checks failed
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
CI / Lint, Typen, Tests, Build (push) Has been cancelled
Die Berichtsseite loest die Position ueber die Besetzung auf -- die Taetigkeit
der Planstelle, auf der die Person am Stichtag sitzt, und nur ersatzweise
employees.job_title. Die Exporte nahmen nur die Spalte. Beides sind
unterschiedliche Angaben, also konnte in der Akte etwas anderes stehen als in
der Datei daneben, ohne dass eines von beidem falsch aussah.

Betrifft die Spalte "Position" im vollstaendigen Datenexport und im
LOLYO-Export.
2026-09-28 13:54:56 +02:00
38e35e2ff9 Kein Formelschutz in einer Datei, die eine Maschine einliest
Some checks failed
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
CI / Lint, Typen, Tests, Build (push) Has been cancelled
Das vorangestellte Hochkomma schuetzt einen Menschen, der eine CSV in Excel
oeffnet: ein Wert mit fuehrendem =, +, - oder @ waere dort sonst eine Formel.
In einer Load-Datei ist es das Gegenteil von Schutz. Jede oesterreichische
Telefonnummer beginnt mit "+", und in LOLYO stuende danach in jedem Konto
'+4366... als Nummer -- ohne dass es beim Erzeugen jemandem auffiele.

toCsv bekommt dafuer formelschutz in der CsvForm, voreingestellt an. Nur LOLYO
schaltet es ab. Die Telefonspalten von Cornerstone sind bisher leer, deshalb
bleibt die Datei dort, wie sie ist.
2026-09-28 13:47:49 +02:00
676cecbf15 Export fuer LOLYO, und die Zielsystem-Exporte in einem eigenen Abschnitt
Some checks failed
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
CI / Lint, Typen, Tests, Build (push) Has been cancelled
LOLYO ist die dritte Datei, die in ein fremdes System geladen wird. Spalten,
Trennzeichen und Schreibweise kommen aus der Vorlage des Anbieters, Zeichen fuer
Zeichen -- einschliesslich der gemischten Kopfzeile ("Titel prefix" deutsch,
"Title Suffix" englisch). Semikolon und kein BOM: das BOM haenge unsichtbar am
Namen der ersten Spalte, und "Benutzer/Code" kaeme in keiner Zuordnung mehr vor.

Der Benutzercode ist die Alpenwerk-UUID. Anders als bei Cornerstone ist das
hier richtig: LOLYO kennt die Person noch nicht und vergibt keine eigene
Kennung, die wir treffen muessten.

Diese Datei legt Konten an, samt Passwort in der Zeile. Das Startpasswort steht
deshalb in der Route und nicht in lib/lolyo.ts: eine Route ist serverseitig, eine
lib-Datei waere nur so lange sicher, wie niemand sie aus einem Client-Bauteil
heraus einbindet -- und das saehe man dem Buendel nicht an. Dieselbe Ueberlegung
steht in lib/passwort.ts.

Die drei Zielsystem-Exporte stehen jetzt unter einer gemeinsamen Ueberschrift,
getrennt vom Datenexport darueber. Der gibt Zahlen heraus, die jemand ansieht;
diese legen im Zielsystem Datensaetze an. Nebeneinander in einer Reihe
gleichartiger Karten war das nicht zu sehen. Die Auswahl steht damit einmal
statt dreimal da.

Der erklaerende Text unter dem Cornerstone-Export entfaellt auf Wunsch des
Kunden.
2026-09-28 13:45:38 +02:00
af2ad53ef9 Die Exportkarten nennen die ganze Auswahl, nicht nur den Status
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m33s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m14s
Das Einschraenken der Downstream-Exporte gab es schon: exportHref reicht die
ganze Adresszeile weiter, und ladeExportMitarbeiter wendet dieselben Kriterien
an wie der Bericht daneben -- Eintritt ab, Austritt bis, Wochenstunden,
Beschaeftigungsart und die uebrigen. Nur sah man es den Karten nicht an. Dort
stand ausschliesslich der Status; alles andere steckt eingeklappt in "Weitere
Kriterien" weiter oben.

Damit sah eine Datei mit 40 Personen genauso aus wie eine mit 785. Fuer einen
Bericht ist das aergerlich, fuer ein Load-File in ein Zielsystem ist es ein
Datenstand, den dort niemand mehr hinterfragt: es fehlen Personen, und es sieht
nicht nach einem Filter aus.

Die drei Karten im Bestandsmodus zeigen jetzt Stichtag, Status, Einheit,
Standort, jedes gesetzte Kriterium und die Zeilenzahl. beschreibeKriterien
steht neben anzahlKriterien in derselben Datei und liest dieselben Listen -- ein
neues Kriterium erscheint damit von selbst auch auf den Karten. Ein Test haelt
beide gegeneinander, damit die Zahl am Aufklapper und der Text auf der Karte
nicht auseinanderlaufen.
2026-09-28 12:25:17 +02:00
677ca35df2 Manager ID verweist ueber die Cornerstone-ID, nicht ueber die Personalnummer
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m53s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m27s
Im Feld Manager stand die Personalnummer der vorgesetzten Person -- also der
Wert, der in derselben Zeile als Local System ID gefuehrt wird. Cornerstone
verknuepft aber ueber die User ID. Der Verweis lief damit entweder ins Leere
oder, schlimmer, auf jemand anderen, dessen User ID zufaellig aussieht wie
eine Personalnummer.

Leer, wenn die vorgesetzte Person selbst keine Cornerstone-ID traegt. Aus
demselben Grund wie bei User ID und Username: eine Kennung der falschen Art
ist schlimmer als keine, weil niemand ihr ansieht, dass sie falsch ist. Bei
435 von 785 Personen fehlt die Kennung noch -- das ist eine Luecke in der
Zuordnungstabelle, kein Fehler im Export.

Die Abbildung im Kontext heisst entsprechend managerKennung und traegt jetzt
Zeichenketten, damit der Typ selbst keine Nummer mehr zulaesst.
2026-09-28 11:13:55 +02:00
779beb4478 Hay-Grade statt Verwendungsgruppe A--F
A--F stammte aus der Spezifikation, nicht vom Kunden: sechs erfundene Stufen
mit erfundenen Beschreibungen. Der Kunde bewertet nach Hay und hat die Liste
geschickt -- 13 Stufen plus einen Generic Grade.

Dieselbe Spalte fuellt im Cornerstone-Extrakt die Grade ID. Solange dort A--F
steht, ist die Datei in jeder Zeile falsch, ohne dass es beim Erzeugen
auffaellt: das Zielsystem kennt diese Kennungen nicht.

Der Typ heisst weiter paygrade_type, ist aber jetzt eine Domain ueber text mit
CHECK statt eines Aufzaehlungstyps. Ein Enum laesst sich nicht umschreiben --
Werte entfernen geht gar nicht, und add value darf im selben Vorgang, der den
neuen Wert schreibt, nicht benutzt werden. Wichtiger: die rund zehn
SQL-Funktionen, die den Wert nach paygrade_type umwandeln, bleiben unveraendert
gueltig. Jede von ihnen neu zu erzeugen hiesse, zehnmal die Gelegenheit zu
haben, aus einer veralteten Vorlage zu kopieren.

Zwei Funktionen muessen doch angefasst werden, beide per Punktaenderung an der
laufenden Definition statt per Kopie aus einer Datei: der Vorgabewert B in
hire_employee und die Beschriftung im Protokoll von promote_employee.

Der Bestand bekommt den Generic Grade. Aus A--F liesse sich kein Hay-Grade
ableiten: andere Einteilung, andere Anzahl. Geraten saehe im Extrakt genauso
aus wie erhoben.
2026-09-28 11:13:41 +02:00
c3e19606e2 Die Cornerstone-ID als eigenes, freiwilliges Feld
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m58s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m24s
Cornerstone fuehrt jede Person unter einer eigenen Kennung. Der Export
dorthin trug in "User ID" und "Username" bisher die Alpenwerk-UUID --
richtig, solange es nichts Besseres gab, aber nicht die Kennung, unter
der Cornerstone die Person kennt. Jetzt steht dort diese Spalte.

Freiwillig, weil die Zuordnungstabelle des Kunden fuer 434 der 784
Personen keine Kennung liefert. Eindeutig, weil eine Kennung genau einer
Person gehoert. Als Text, weil fuehrende Nullen in einer numerischen
Spalte verlorengingen.

Ohne hinterlegte Kennung bleiben User ID und Username **leer**. Ein
Rueckfall auf die UUID braechte zwei Kennungsarten in eine Datei, ohne
dass es auffiele, und legte in Cornerstone eine zweite Person neben der
bestehenden an. Eine fehlende Angabe soll fehlen; dafuer gibt es einen
eigenen Test.

Fuenf Funktionen mussten mit -- dieselbe Liste und derselbe Grund wie bei
der Firmen-E-Mail: hire_employee und rehire_employee teilen sich den
Schritt "Person", change_employee_data macht das Feld aenderbar,
apply_due_pending_changes sorgt dafuer, dass eine datierte Aenderung
nicht verfaellt, app_feld_karte haelt den Eintrag in der Historie
richtigstellbar. Die Migration ist wieder erzeugt, nicht abgeschrieben,
und prueft jede der fuenf einzeln.

Erfasst wird das Feld in der Akte, in "Daten aendern", bei Einstellung
und Wiedereintritt sowie ueber den Massenimport; es steht im
Mitarbeiterexport und fuellt im Cornerstone-Export User ID und Username.
2026-09-28 10:13:52 +02:00
6717412c9f User ID and Username carry the Alpenwerk UUID
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m2s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m6s
Both columns now hold employees.id, and they hold the same value: in
Alpenwerk the user name and the user id never diverge. If they did,
Cornerstone would show two identities for one person and every
reference to them -- manager, reports -- could hit the wrong one.

The UUID rather than the personnel number, because it is the identifier
that never changes. A personnel number can be corrected, and the person
would then be somebody else in Cornerstone.

Local System ID keeps the personnel number as LOGA assigns it, which is
what that column is for. Customfield ID AD keeps the directory account
name (vorname.nachname); it is a separate thing from the Cornerstone
user name and always was.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-27 20:25:41 +02:00
410acfe01f Cornerstone Report: system values, not display names
Some checks failed
CI / Lint, Typen, Tests, Build (push) Successful in 11m34s
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
Reworked against the load spec and the 27.09. test file. The values I
had guessed were the German display names, which is the first entry on
the list of errors from earlier loads: Cornerstone answers "ungültiger
Wert" and rejects the whole row, followed by "Alle abhängigen Felder
müssen gültig sein" as a follow-on.

  Status            Aktiv/Inaktiv    -> Active/Inactive
  Employment Status Arbeitend/...    -> Working/On Leave/Terminated
  User Type         Mitarbeiter      -> Employee
  Time Zone         CET              -> empty

The time zone is the second entry on that list: only a portal time zone
id is valid, an abbreviation gives "Zeitzonencode nicht eindeutig".
Empty means the portal or the OU decides.

Division ID is the GUID from the test file, not a name. Termination
fields and Leave Reason are filled only when the employment status
carries them -- a reason without a termination is an invalid state for
the load, not extra information.

Four fields now stay empty on purpose, because filling them would mean
inventing an identifier that belongs to the target system: Location ID
(locations has id/name/country and no Cornerstone id), Position ID (our
S-0001 is not a Cornerstone position), Months of Service (Cornerstone
derives it) and Rehired Employee (the value for "yes" is unconfirmed,
and an unconfirmed value costs the whole row). Retention Rules and
Organisationsstufe stay empty because the load ignores them.

Header and row now match the test file byte for byte, except User ID
(no TEST- prefix outside a test load), Required Training Approvals and
Location ID.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-27 20:10:56 +02:00
478364e2d0 Add the Cornerstone export to Berichte
The 57 columns of the Cornerstone user import, in the given order and
spelling, offered as CSV and Excel under the Honestly report. Same
people and same filters as the full export.

Two things about the file itself, both of which would have failed
quietly. Cornerstone reads comma-separated, while toCsv writes the
semicolons and the BOM that German Excel wants -- the BOM would have
hidden inside the name of the first column, so "User ID" would have
matched nothing in the mapping. toCsv now takes the form as an argument
and keeps its old defaults; the Cornerstone form lives next to the
columns so a test can hold both. Quoting follows the delimiter now,
otherwise a comma in an address would split the row.

Dates go out day-first, matching the import setting. An ISO date is
read as a different, equally valid date and nobody notices.

Gender maps to Cornerstone's own values; anything unexpected becomes
"not specified" rather than empty, because an invalid value makes
Cornerstone reject the whole row, not just the field.

Status and Employment Status come from separate rules: somebody on
Karenz has a working account and is not working, and filling both from
one value gets one of the two wrong.

Four fields carry visible placeholders because the leading systems do
not supply their identifiers yet: Division ID, Doxis, Interflex,
LGVplus. Home Phone and Personal Email stay empty on purpose -- what
leaves the house is the business data.

Not verified against a running Cornerstone import, and not seen in a
browser; there is no database reachable here.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-25 11:21:25 +02:00
e11544b8da Die Messung wieder entfernen -- die Ursache steht fest
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m17s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m13s
Die Akte oeffnet jetzt in rund 100 ms statt in 1,5 s:

  vorher   person 4ms, hauptabfrage 1554ms, nachschlag 11ms, gesamt 1569ms
  nachher  person 2ms, hauptabfrage  79ms, nachschlag  7ms, gesamt   87ms

Gefunden hat das der vorlaeufige console.info in dieser Datei, nicht das
Nachdenken darueber. Behoben haben es zwei Migrationen: die Policies
pruefen die Rechte einmal je Abfrage (20260924200000), und
om_reporting_lines laeuft als security definer mit require_hr_admin in
der ersten Zeile (20260924220000).

Nebenbei die Behauptung im Kopf der Datei richtiggestellt: dort standen
"rund 36 ms Umlaufzeit" als Begruendung dafuer, die Zahl der Rundreisen
zu druecken. Nachgemessen sind es 0,5 ms. Die Rundreisen waren nie das
Problem.
2026-09-24 12:39:50 +02:00
520242e3c3 Die Selbstpruefung ruft die Funktion nicht mehr auf
Some checks failed
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
CI / Lint, Typen, Tests, Build (push) Has been cancelled
Die Migration ist an ihrer eigenen Pruefung gescheitert:

  FEHLGESCHLAGEN 20260924220000_reporting_lines_ohne_zeilenschutz.sql
  Nicht berechtigt: nur aktive HR-Benutzer:innen duerfen diese Aktion
  ausfuehren.

Die Pruefung verglich die Zeilenzahl der neuen Funktion mit der Zahl der
laufenden Besetzungen -- und rief sie dafuer auf. Die Funktion verlangt
seit dieser Migration HR-Rechte, die Migration selbst laeuft aber als
Administrator ohne app.user_id. require_hr_admin() hat sie also zu Recht
abgewiesen.

Nichts wurde eingespielt, die Transaktion ist vollstaendig
zurueckgerollt.

Jetzt wird der Koerper gelesen statt ausgefuehrt: geprueft wird, dass
require_hr_admin, security definer und der search_path stehen und dass
die Bestandteile der Abfrage vollzaehlig uebertragen sind. Eine
Selbstpruefung darf nichts aufrufen, was einen angemeldeten
Anwendungsbenutzer voraussetzt.
2026-09-24 12:33:19 +02:00
6d006e55fe om_reporting_lines prueft die Rechte einmal statt je Zeile
Some checks failed
CI / Lint, Typen, Tests, Build (push) Successful in 11m10s
CI / Migrationen auf leerer Datenbank (push) Failing after 5m29s
Die Akte brauchte 1,3 bis 1,5 s, davon ueber 1,1 s in dieser Funktion.
Als postgres -- am Zeilenschutz vorbei -- kostet dieselbe Funktion 60 ms.

  als postgres                             60 ms
  als alpenwerk_app, vor 20260924200000  1457 ms
  als alpenwerk_app, danach              1153 ms

Die vorige Migration fasste die Policies so, dass is_hr_user() je Abfrage
einmal laeuft. Das half um ein Fuenftel -- die Pruefung war also nicht der
Hauptposten.

Die Teile der Funktion sind einzeln billig, unter Zeilenschutz gemessen:
Besetzungen 12 ms, Vorfahrenkette 7 ms, Leitungen 9 ms. Zusammen 28 ms,
die Funktion daraus 1153. Die Kosten entstehen beim Zusammensetzen: unter
Zeilenschutz wird aus jeder Tabellenreferenz eine Unterabfrage mit
Sicherheitsschranke, und der Planer verliert die Freiheit, die
Zwischenmengen einmal zu berechnen -- die beiden Unterabfragen am Ende
laufen dann fuer jede der 784 Zeilen erneut.

Jetzt security definer mit require_hr_admin() in der ersten Zeile. Das ist
dieselbe Bedingung, die in den Policies aller vier gelesenen Tabellen
steht -- require_hr_admin() ist woertlich "if not is_hr_user() then
raise". Sie wird einmal gestellt statt hunderttausendfach. Wer Daten
bekommt, aendert sich nicht; eine unberechtigte Anfrage bekommt jetzt eine
Meldung statt einer leeren Antwort.

Der Preis: diese Funktion liest die vier Tabellen am Zeilenschutz vorbei.
Kaeme je eine feinere Rechteordnung, muesste sie eigens nachgezogen
werden. Mit dem Eigentuemer besprochen -- solche Rollen sind nicht
vorgesehen.

Der Koerper ist unveraendert aus 20260727120100, der einzigen textlichen
Fassung. Geaendert sind Sprache, security definer, search_path und die
erste Zeile.
2026-09-24 12:13:42 +02:00
a1b4674a22 Die Rechtepruefung in den Policies einmal je Abfrage statt je Zeile
Some checks failed
CI / Lint, Typen, Tests, Build (push) Successful in 11m10s
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
Die Personalakte brauchte beim Oeffnen anderthalb Sekunden. Im Container
gemessen: person 4ms, hauptabfrage 1554ms, nachschlag 11ms. In der
Hauptabfrage steckt om_reporting_lines -- als postgres 60 ms, als
alpenwerk_app 1457 ms. Derselbe Aufschlag liegt auf allem: ein blosses
count(*) kostet unter RLS 44 bis 55 ms statt 7.

Ursache: ein Policy-Ausdruck wird je Zeile ausgewertet. `is_hr_user()` ist
zwar stable, aber das erlaubt Postgres nur, den Wert innerhalb einer
Anweisung als unveraenderlich anzusehen -- nicht, ihn aus dem Zeilenfilter
zu ziehen. Bei jeder Zeile laufen zwei Unterabfragen auf profiles und
app_passwoerter.

In einen Unterausdruck gefasst wird daraus ein InitPlan, einmal
ausgewertet. Ohne RLS gemessen, damit nur dieser Unterschied sichtbar ist:

  om_positions where is_hr_user()           14,8 ms
  om_positions where (select is_hr_user())   0,5 ms
  employees    where is_hr_user()            4,1 ms
  employees    where (select is_hr_user())   0,5 ms

Die Zugriffsentscheidung aendert sich nicht: dieselbe Funktion, dasselbe
Ergebnis, nur nicht mehr achthundertmal gefragt. Keine Tabelle verliert
ihre Policy, keine Rolle bekommt Rechte dazu, alpenwerk_app bleibt ohne
BYPASSRLS.

Der andere Weg -- om_reporting_lines auf security definer umstellen --
waere genau das nicht: er verschoebe die Grenze, um schneller zu werden,
und haelfe nur dieser einen Funktion.

Rund zwanzig Policies von Hand abzuschreiben hiesse, eine davon falsch zu
treffen und eine Tabelle zu oeffnen oder zu schliessen, ohne dass es
auffaellt. Deshalb werden die bestehenden Definitionen aus pg_policies
gelesen und unveraendert wieder angelegt; ersetzt wird allein der
Funktionsaufruf. Die Selbstpruefung zaehlt nach, dass keine offen blieb
und keine verlorenging.
2026-09-24 12:01:58 +02:00
c8f9ae8047 Vorübergehend messen, woher die anderthalb Sekunden der Akte kommen
Some checks failed
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
CI / Lint, Typen, Tests, Build (push) Has started running
Die Akte braucht beim Oeffnen rund 1,5 s. Die Datenbank ist es dem
Anschein nach nicht: eine Rundreise kostet 0,5 ms (nicht 36, wie der
Kommentar hier behauptete), und om_reporting_lines misst 60 ms. Damit
laegen unter zehn Prozent der Zeit in den Abfragen.

Statt weiter zu raten -- heute schon zweimal danebengelegen -- schreibt
loadEmployeeDetail eine Zeile ins Protokoll des Containers: Zeit fuer die
Person, fuer die Hauptabfrage, fuer die Nachschlaege, insgesamt, und wie
viele Berichtslinien uebertragen wurden.

Wieder entfernen, sobald die Ursache feststeht.
2026-09-24 11:52:36 +02:00
499d400fe1 Die Berichtslinie einmal ausrechnen statt zweimal
Some checks failed
CI / Lint, Typen, Tests, Build (push) Successful in 11m7s
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
Die Akte holte Vorgesetzte und direkte Berichte in zwei Teilabfragen, je
eine mit eigenem Filter -- in der Annahme, der Filter schraenke die
Funktion ein. Tut er nicht. om_reporting_lines traegt ein `with
recursive` im Koerper und laesst sich deshalb nicht einbetten; sie rechnet
jedes Mal alle Zeilen aus, und der Filter wirft sie danach weg.

Auf dem Server gemessen:

  explain analyze select * from om_reporting_lines(current_date)
    where employee_id = ...;
  -> Rows Removed by Filter: 783, Execution Time: 69 ms

Und ohne Filter dieselben 60 ms. Zwei Filter hiessen also zweimal
dieselbe Rechnung, rund 120 ms je Aufruf der Akte -- der groesste
Einzelposten der Seite.

Jetzt ein Aufruf, und die Auswahl trifft der Aufrufer. Dafuer wandern
einmal alle Zeilen herueber statt neun; ueber eine Verbindung im selben
Netz kostet das den Bruchteil dessen, was die zweite Rechnung kostete.

Der Kommentar, der das Gegenteil behauptete, ist durch die Messung
ersetzt.
2026-09-24 11:39:24 +02:00
e6b7defae2 Eine datierte Stammdatenaenderung verlor fuenf Felder
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m30s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m6s
change_employee_data schreibt bei einem Stichtag in der Zukunft nicht in
die Zeile, sondern legt einen Eintrag in pending_org_changes an; am
Stichtag traegt ihn apply_due_pending_changes nach. Dessen Zweig
contract_change kannte fuenf Spalten nicht, die der sofortige Weg
schreibt: die drei Felder des Notfallkontakts und beide Titelfelder.

Wer also den Notfallkontakt oder einen akademischen Titel zu einem
kuenftigen Datum erfasste, sah den Vorgang in der Personalakte, und am
Stichtag geschah nichts. Der Eintrag wurde auf "applied" gesetzt, die
Zeile blieb unveraendert, eine Meldung gab es nicht.

Gefunden durch einen Abgleich beider Wege: 44 Spalten schreibt
change_employee_data sofort, 39 der Nachtlauf. Jetzt 44 zu 44. Dieselbe
Luecke wie bei der Gruppe `role` (20260915120000) und bei der Besetzung im
Zweig `transfer` (20260924100000) -- und derselbe Weg, sie zu finden.

Die Selbstpruefung nennt die fuenf Felder ausdruecklich und prueft
zusaetzlich weiter, was hier schon einmal verlorenging.
2026-09-23 20:34:40 +02:00
e5aa527473 Angehoerige berichtigen, und beide Abschnitte sehen gleich aus
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m26s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m15s
Angehoerige liessen sich bisher nur anlegen und entfernen. Ein Tippfehler
im Namen war nur zu beheben, indem man die Person loeschte und neu
anlegte -- zwei Eintraege in der Akte fuer eine Korrektur, und der erste
sagte "entfernt", was nicht stimmte. Jetzt steht in jeder Zeile ein Stift,
wie beim Notfallkontakt.

update_employee_dependent kommt bewusst **ohne** Stichtag. Hinzufuegen und
Entfernen tragen einen, dort passiert etwas zu einem Zeitpunkt. Eine
Berichtigung nicht: der Wert war schon vorher falsch, und ein "wirksam ab"
hiesse, die Person habe bis dahin anders geheissen. Der Eintrag in der
Akte nennt deshalb Vorher und Nachher statt eines Datums.

In "Daten aendern" standen fuer den Notfallkontakt drei Eingabefelder,
waehrend die Angehoerigen darueber als Tabelle mit Knoepfen erscheinen --
zwei Bauformen fuer denselben Zweck, direkt untereinander. Dort steht
jetzt derselbe Abschnitt wie im Reiter "Stammdaten"; beide laufen ueber
das "Wirksam ab" des Formulars, wie die Angehoerigen es schon taten.

Damit schreibt auch nur noch eine Stelle diese drei Spalten. Vorher
schickte das Formular sie zusaetzlich im eigenen Aufruf mit.
2026-09-23 20:03:43 +02:00
2bba1f40ac Die Migration gegen auth.uid() zuruecknehmen -- sie war falsch und gefaehrlich
Some checks failed
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
CI / Lint, Typen, Tests, Build (push) Has been cancelled
Die Annahme war, acht Funktionen riefen weiterhin auth.uid() und
scheiterten deshalb an den Rechten der Anwendungsrolle. In der Datenbank
ist das nicht so:

  select proname, prosecdef, pg_get_functiondef(oid) like '%auth.uid()%'
  -- alle acht: ruft_auth_uid = f

Der Grund: 20260805110000_replace_auth_uid_in_functions.sql liest die
Definition jeder Funktion, ersetzt den Text und legt sie neu an. Es gibt
rund ein Dutzend solcher Migrationen. Wer die *textliche* letzte Fassung
in den Migrationsdateien sucht, sieht diese Aenderungen nicht -- genau das
hatte ich getan.

Damit war die Migration nicht nur ueberfluessig, sondern schaedlich: sie
haette die acht Funktionen mit Koerpern aus alten Dateien ueberschrieben
und jeden danach aufgetragenen Patch stillschweigend entfernt. Also genau
der Fehler, gegen den sie sich richtete.

Sie wurde nie eingespielt. Die Lehre steht in CLAUDE.md: massgeblich ist
der Katalog der laufenden Datenbank, nicht die Summe der Dateien.
2026-09-23 19:53:19 +02:00
01c49ee56c Acht Funktionen riefen auth.uid() -- und scheiterten damit vollstaendig
Some checks failed
CI / Lint, Typen, Tests, Build (push) Successful in 11m11s
CI / Migrationen auf leerer Datenbank (push) Failing after 5m18s
Die Attrappe des Supabase-Schemas gibt der Anwendungsrolle mit Absicht
kein usage auf `auth`: "fiele je wieder ein Bezug auf dieses Schema in
den laufenden Betrieb, soll er scheitern und nicht stillschweigend
funktionieren." Er ist gefallen, und sie scheitern.

Auf dem Server nachgemessen, nicht vermutet:

  select has_schema_privilege('alpenwerk_app', 'auth', 'usage');  -- f
  set local role alpenwerk_app; select auth.uid();
  -- ERROR: permission denied for schema auth

Keine der acht ist security definer, sie laufen also mit den Rechten der
Anwendungsrolle. Betroffen war je eine vollstaendige Operation:
Versetzung, Planstelle anlegen, Planstelle loeschen, Angehoerige
hinzufuegen und entfernen, HR-Notiz anlegen und erledigen, Rueckkehrdatum
verschieben.

Der Umstieg auf app_current_user_id() geschah im August und danach
Funktion fuer Funktion, sobald eine ohnehin angefasst wurde. Diese acht
wurden seither nicht mehr angefasst, und nichts prueft den Rest: die
Migrationen laufen durch, die Tests kennen keine Datenbank, und wer die
Oberflaeche bedient, bekommt die Meldung erst beim Speichern.

Geaendert ist nur zweierlei je Funktion -- auth.uid() wird
app_current_user_id(), und der search_path steht fest. Die Koerper sind
unveraendert aus ihren letzten gueltigen Fassungen uebernommen.

Die Selbstpruefung geht das ganze Schema durch statt nur die acht: sie
schlaegt an, sobald irgendeine Funktion in public das Schema auth wieder
anfasst, und prueft zusaetzlich, dass das Recht entzogen bleibt.
2026-09-23 19:00:51 +02:00
37650ee9a4 Befoerderung wahlweise auf eine neue Planstelle -- und der Nachtlauf, der sie ausfuehrt
Some checks failed
CI / Lint, Typen, Tests, Build (push) Successful in 11m9s
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
Bei "Befoerdern" steht jetzt die Wahl: selbe Planstelle oder eine neue.
Bei "neu" wird sie aus den freien gewaehlt, dieselbe Auswahl wie die
Zielplanstelle bei der Versetzung, und die Stelle schlaegt ihre
Taetigkeit als neue Bezeichnung vor -- nur als Vorschlag, denn
job_title darf von der Planstelle abweichen.

Die Zielstelle muss frei sein, mit derselben Meldung wie bei der
Versetzung. Ausgenommen ist die eigene: darauf sitzt die Person schon,
und "bereits besetzt" waere eine Falschaussage ueber sie selbst.

Dabei ist ein aelterer Fehler aufgefallen. transfer_employee legt fuer
ein kuenftiges Datum einen Eintrag in pending_org_changes mit
target_position_id an. Der Nachtlauf hat die Besetzung dort zur
Umstellung auf Planstellen (20260727120200) umgehaengt; zuletzt stand in
diesem Zweig nur noch

    update employees set job_title = coalesce(payload->>'new_title', ...)

also die Fassung von *vor* jener Umstellung -- und new_title kommt in
diesem payload gar nicht vor. Eine auf spaeter datierte Versetzung wurde
am Stichtag auf "applied" gesetzt und bewegte niemanden: die Person blieb
auf ihrer alten Planstelle, im Organigramm unveraendert, ohne Meldung.
Eine der Migrationen dazwischen hat die Funktion aus einer alten Vorlage
neu geschrieben -- dieselbe Falle wie bei der Gruppe `role` und bei der
Anmerkung zum Austritt.

Beide Zweige haengen die Besetzung jetzt um, und die Selbstpruefung
zaehlt nach, dass es zwei sind. Nebenbei bekommt promote_employee den
festen search_path und app_current_user_id() statt auth.uid().
2026-09-23 18:41:41 +02:00
93cb1c1699 Den Notfallkontakt wie die Angehoerigen darstellen
Some checks failed
CI / Lint, Typen, Tests, Build (push) Successful in 11m39s
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
Beide Abschnitte stehen im selben Reiter und zeigen dasselbe: Personen im
Umfeld. Die Angehoerigen standen in einer Tabelle, der Notfallkontakt in
einer Beschreibungsliste -- zwei Baustile untereinander, ohne dass ein
Unterschied in der Sache dahintersteht.

Jetzt dieselbe Tabelle mit denselben Spaltenkoepfen, und Aendern und
Entfernen als Symbole in der Zeile, wie dort das Entfernen. Der Knopf
"+ Hinzufuegen" steht nur, solange kein Kontakt hinterlegt ist: es gibt
genau einen, und ein Knopf daneben verspraeche eine Liste. Die
Telefonnummer bleibt waehlbar.
2026-09-23 18:29:53 +02:00
db02fb4762 Elf Punkte aus der Rueckmeldung, und die verlorene Anmerkung
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m23s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m18s
Kleinigkeiten zuerst: "Gelaufen" heisst jetzt "Vergangen", die Kachel
"Langzeitabwesend" heisst "Langzeitabwesende", "Eintritte/Austritte
(Jahr)" heissen "(YTD)" -- gezaehlt wurde ohnehin seit Jahresbeginn.
"Personenkreis" heisst "Grund". Der Hinweis unter dem Grad der
Behinderung und der Erklaertext ueber dem Honestly-Report sind weg.
"Gehaltsanpassung" steht nicht mehr im Filter des Protokolls: das Gehalt
ist aus dem Funktionsumfang, keine Funktion schreibt die Art mehr, und
ein Filter, der immer leer ausgeht, sieht aus wie ein Fehler.

Im Fenster fuer den Notfallkontakt faellt "Wirksam ab" weg -- eine
Telefonnummer fuer den Ernstfall gilt ab sofort. In "Daten aendern"
wandert der Block unter die Angehoerigen, dieselbe Reihenfolge wie im
Reiter "Stammdaten". Auf der Uebersicht fuehren die Namen unter "Letzte
Aktivitaeten" in die Akte; vorher war die Karte eine Sackgasse.

"Eintrag berichtigen" bot fuer jedes Feld ein Textfeld an, auch fuer
"Notfallkontakt Verhaeltnis", wo die Erfassung sonst eine Liste fuehrt.
Wer dort "Gattin" statt "Gattin/Gatte" tippte, erzeugte einen Wert, den
keine Auswertung mehr findet -- die Berichtigung schreibt in dieselbe
Spalte wie das Formular, nur ohne dessen Pruefung. Welche Felder eine
Liste bekommen, steht in lib/historie-felder.ts; ein Test prueft jeden
Schluessel gegen app_feld_karte(), damit ein Tippfehler dort nicht still
auf ein Textfeld zurueckfaellt. Felder mit Aufzaehlungstyp bleiben
bewusst aussen vor: dort ist der gespeicherte Wert nicht die Anzeige.

Und die Antwort auf "wo sieht man die Anmerkung beim Austritt?": nirgends.
Das Formular sammelte sie ein, terminate_employee liess sie fallen. Bis
20260814100000 stand sie in der Beschreibung des Ereignisses; beim
Umschreiben fuer den Nichtantritt ging sie verloren, und die Migration
fuer die Austrittsart reichte die verkuerzte Fassung weiter. Sie steht
jetzt wieder in der Personalakte und im Protokoll, und die Selbstpruefung
faengt den naechsten Verlust ab.
2026-09-23 16:01:05 +02:00
5e35d6bf41 Eine geleerte freiwillige Angabe ist null, nicht die leere Zeichenkette
Some checks failed
CI / Lint, Typen, Tests, Build (push) Successful in 11m49s
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
Beim Speichern in "Daten aendern" brach es ab, sobald bei einer zweiten
Person das Feld "E-Mail (privat)" leer blieb:
duplicate key value violates unique constraint "employees_email_key".

email war bis 20260811140000 NOT NULL -- jede Person hatte eine, das Feld
war nie leer. Seither ist die Angabe freiwillig, aber
change_employee_data schrieb weiter `coalesce(v_person->>'email', email)`.
Ein leeres Formularfeld kommt als "" an, und "" ist nicht null: es landete
als leere Zeichenkette in der Spalte. Beim ersten Mal ging das gut, beim
zweiten schlug der eindeutige Index zu -- "" ist gleich "", waehrend null
nie gleich null ist.

Aufgefallen ist es erst jetzt, weil die Spieldaten durchweg Adressen
trugen. Die 784 uebernommenen Personen tragen keine.

Alle freiwilligen Textfelder bekommen deshalb dieselbe Form wie der
Notfallkontakt und die Firmen-E-Mail: `case when ? then nullif(…, '')`.
Fehlt der Schluessel, bleibt der alte Wert; steht er leer da, wird das
Feld geleert -- die Absicht, die jemand ausdrueckt, wenn er eine Angabe
herausloescht. first_name, last_name, gender, birth_date und nationality
bleiben ausgenommen, sie sind NOT NULL.

Der Nachtlauf bekommt dieselbe Behandlung, sonst liefe eine auf spaeter
datierte Aenderung in denselben Index -- um drei Uhr frueh und ohne
jemanden, dem die Meldung angezeigt wuerde. Was bereits als "" in der
Datenbank steht, raeumt die Migration auf; sonst blockierte diese eine
Zeile weiterhin jede weitere Person ohne Adresse.
2026-09-23 15:42:43 +02:00
948ddf5c70 Verhaeltnis als Auswahlliste, und im Organigramm keine Vakanz ganz oben
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m41s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m16s
Zwei Nachtraege zur Rueckmeldung des Kunden.

Das Fenster fuer den Notfallkontakt hatte ein Freitextfeld fuer das
Verhaeltnis, waehrend der Einstellungsassistent und "Daten aendern"
dieselbe Auswahlliste fuehren (EMERGENCY_RELATIONS). Freitext hiesse,
dass "Gattin", "Ehefrau" und "Frau" nebeneinander stehen und sich nicht
auswerten lassen -- genau der Grund, aus dem die Liste ueberhaupt
existiert. Jetzt fuehren alle drei Stellen dieselbe.

Und "Leitung vakant" stand im Organigramm weiterhin bei der obersten
Einheit. Entfernt wurde es zuletzt nur im Druck; die Ansicht am
Bildschirm hat ihre eigene Beschriftung. Die Gesellschaft wird nicht
gefuehrt, sondern ist das Ganze -- der Vermerk las sich dort wie eine
offene Stelle und faerbte den obersten Knoten obendrein als Vakanz ein.
Ueberall sonst bleibt er.
2026-09-23 12:58:57 +02:00
57acbfae9d Die Firmen-E-Mail als eigenes, freiwilliges Feld
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m29s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m27s
employees.email ist die private Adresse (20260811140000). Sie taugt nicht
als Dienstadresse und darf auch nicht als solche benutzt werden: der
Honestly-Export geht an einen fremden Anbieter, der damit im Namen des
Arbeitgebers einlaedt. Die Spalte "Email" stand dort deshalb seit jeher
leer, mit einem Vermerk in lib/honestly.ts, dass die Firmenadresse im
Datenmodell fehlt. Jetzt gibt es sie, und die Spalte fuellt sich.

Eindeutig, aber freiwillig -- mehrere Personen ohne Adresse stoeren den
Index nicht, weil null nie gleich null ist. Geschrieben wird ueber
`case when ? then nullif` statt `coalesce`: eine Dienstadresse muss sich
auch wieder entfernen lassen.

Vier SQL-Funktionen mussten mit, weil `create or replace` die ganze
Fassung ersetzt und ein ausgelassenes Feld dort still verschwindet:
hire_employee und rehire_employee (beide teilen sich den Schritt
"Person" -- das Formular haette das Feld gezeigt und den Wert
weggeworfen), change_employee_data (sonst nicht aenderbar),
apply_due_pending_changes (sonst verfiele eine auf spaeter datierte
Aenderung) und die Feldkarte (sonst waere der Eintrag in der Historie
nicht korrigierbar). Die Selbstpruefung am Ende prueft jede einzeln.
2026-09-23 10:52:26 +02:00
1816ab68ad Den Notfallkontakt an Ort und Stelle anlegen statt ueber "Daten aendern"
Bei den Angehoerigen steht ein "+ Hinzufuegen", beim Notfallkontakt stand
nichts: der einzige Weg zu einer Telefonnummer fuehrte ueber ein Formular
ueber saemtliche Stammdaten. Jetzt steht der Knopf an derselben Stelle,
mit einem Fenster fuer Name, Telefonnummer und Verhaeltnis; ist ein
Kontakt hinterlegt, heisst er "Aendern" und daneben laesst er sich
entfernen.

Geschrieben wird ueber dieselbe Funktion wie in "Daten aendern" --
change_employee_data mit nur den drei Feldern. Der Eintrag landet damit
in der Historie und im Protokoll wie jede andere Stammdatenaenderung. Die
Datenbank fasst nur die Felder an, die im Aufruf stehen: sie prueft auf
das Vorhandensein des Schluessels, nicht auf seinen Wert (Migration
20260917120000, Zeilen 209-211). Adresse, E-Mail und der Rest bleiben
unberuehrt.
2026-09-23 10:41:24 +02:00
1baf8c2867 Im Druck jeden untersten Bereich als Blatt, und die Zwischenebene zeichnen
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 12m9s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m41s
Die Blaetter kamen aus `root.children`, also aus den unmittelbaren Kindern
der Gesellschaft. Das stimmte, solange die Bereiche dort hingen. Beim
Kunden liegt "CEO" dazwischen und ist selbst ein Bereich: die Auswahl bot
einen einzigen Eintrag an, und aus 784 Personen wurde die Uebersicht plus
ein Blatt fuer CEO.

Genommen wird jetzt jeder Bereich, unter dem kein weiterer liegt -- nach
dem Etikett und nicht nach der Stellung im Baum. Nur nach dem Etikett zu
gehen genuegte nicht: CEO kaeme als eigenes Blatt dazu und enthielte die
sechs anderen noch einmal.

Die Uebersicht haengte die gewaehlten Bereiche unmittelbar unter die
Gesellschaft und haette CEO damit stillschweigend uebersprungen. Sie
zeichnet jetzt den echten Weg von oben, beschnitten auf die Aeste mit
einem gewaehlten Bereich, und geht so tief, wie dieser Baum reicht. Das
Ab- und Anwaehlen wirkt weiterhin bis in die Uebersicht.

Bei der Gesellschaft entfaellt "Leitung unbesetzt": sie wird nicht
gefuehrt, sondern ist das Ganze. Ueberall sonst bleibt der Vermerk.
2026-09-23 10:19:53 +02:00
33d4582b30 In der Mitarbeiterliste nur die eigene Einheit zeigen, nicht den Bereich
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m33s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m17s
Die Spalte fuehrte zwei Zeilen: den Bereich und darunter die Einheit der
Person. Beim Kunden heissen die Bereiche CEO, CFO, CSMO, CPO, COO, CHRO --
Rollenbezeichnungen, die ueber jedem Namen dasselbe wiederholten. Auf
seinen Wunsch bleibt nur die Einheit stehen; der ganze Weg von oben steht
weiterhin im title, denn eine Einheit wie "Shopleitung" sagt allein nicht,
welche gemeint ist.

Sortiert wird jetzt ebenfalls nach der Einheit. Bliebe der Bereich das
erste Kriterium, ordnete die Spalte nach einem Wert, den sie nicht mehr
anzeigt -- von aussen sieht das aus wie gar keine Sortierung. Der
rekursive Ausdruck aus 3e49be5 entfaellt damit; divisionOf bleibt in
Gebrauch, die Uebersicht gruppiert weiter nach Bereich.
2026-09-22 16:52:23 +02:00
d08e4f86fe Den Bereich einer Einheit ueber das Etikett suchen, nicht ueber die Stellung
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m34s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m17s
divisionOf nahm "die oberste Einheit unterhalb der Gesellschaft" -- eine
Aussage ueber die Stellung im Baum statt ueber unit_type. Im Altmodell
fiel beides zusammen, weil unter der Gesellschaft genau die Bereiche
hingen. Bei Manner liegt dort allein "CEO", darunter erst die sechs
C-Level-Bereiche: die Funktion gab fuer alle 784 Personen "CEO" zurueck.
In der Mitarbeiterliste stand es in jeder Zeile, auf der Uebersicht lag
die ganze Belegschaft im Balken "CEO", waehrend die sechs uebrigen
Bereiche auf null standen.

Gesucht wird jetzt der naechste Vorfahre mit unit_type = 'Bereich', die
Einheit selbst eingeschlossen. Der naechste und nicht der oberste: "CEO"
ist selbst ein Bereich und liegt ueber den anderen, sonst stuende er
wieder ueberall. Damit meinen Liste, Uebersicht, Sortierung
(lib/employee-sort.ts) und Berichte (lib/reports-data.ts) denselben
Bereich -- vorher sortierte die Liste bereits richtig, zeigte aber in
der Spalte etwas anderes an.
2026-09-22 15:10:31 +02:00
3e49be5fc1 Den Bereich fuer die Sortierung rekursiv suchen, nicht in zwei Spruengen
Some checks failed
CI / Lint, Typen, Tests, Build (push) Successful in 11m47s
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
Der Ausdruck stieg mit zwei `left join` nach oben, weil der Baum als
hoechstens vierstufig galt. `unit_type` ist aber nur ein Etikett, und die
Organisation kann beliebig tief sein: bei Manner sind es sieben Ebenen.
Fuer 317 der 784 Personen lag der Bereich drei oder vier Spruenge ueber
der eigenen Einheit, der Ausdruck lieferte null, und diese 317 rutschten
beim Sortieren nach Bereich/Team nicht unter ihre Bereiche, sondern
allesamt in einen Block am Ende der Liste.

Der Aufstieg haelt beim ersten Bereich an, nimmt also den naechsten und
nicht den obersten -- sonst stuende bei fast allen "CEO", weil diese
Einheit ueber den sechs C-Level-Bereichen liegt und selbst einer ist.
Dieselbe Regel gilt in lib/reports-data.ts, das von der Wurzel absteigt
und den letzten Treffer nimmt; dort gab es den Fehler nicht.

Gegen den Bestand geprueft: vorher 467 von 784 mit Bereich, jetzt 784.
2026-09-22 14:54:51 +02:00
683e7cc2d7 Keep private email out of the Honestly export
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m30s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m6s
The Email column exported employees.email, which is the person's
private address. That does not belong in a file sent to an outside
survey provider, least of all as the address invitations go to in the
employer's name.

The column now stays as a placeholder for the work email, which does
not exist in the schema yet and will be added later. It is empty until
then, but keeps its place so the column mapping set up in Honestly does
not have to change once the address arrives. The export no longer
reads employees.email at all, so it cannot end up in another column
by accident either.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-18 15:10:44 +02:00
779d6116b2 Add the Honestly survey export to Berichte
A participant list for the employee survey on honestly.de, offered as
CSV and Excel right under the full data export. Columns: Personalnummer,
Email, Firstname, Last Name, Language, Location, OU, OU+1, ... , Role.
Language is always "de", Role always "Respondee".

The org columns run bottom-up: OU is the person's own unit, OU+1 the one
above, up to the top node. Their number follows the deepest chain in
the file, shorter chains are padded with empty cells, and there is
always at least one OU column so the file keeps its shape.

It exports exactly the people the full export would, with the same
filters. To guarantee that, the selection moved out of the full export's
route into lib/export-auswahl.ts and both routes use it; the full
export's columns are untouched.

Email is employees.email, which is the private address and optional --
there is no work address in the schema. Missing addresses stay empty
rather than getting a placeholder that would receive an invitation.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-18 15:10:43 +02:00
7b7562799d Die Rueckfragen auf den Stand nach dem Gespraech bringen
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m36s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m5s
Vier der sieben Fragen sind am 17.09.2026 geklaert. Sie stehen jetzt mit dem
Ergebnis im Dokument, damit nachvollziehbar bleibt, warum etwas so ist, wie
es ist — nicht geloescht, denn die Begruendung ist die Antwort.

Offen bleiben: die fehlenden Punkte 6 und 7 im Anforderungsdokument, was
"Niederlassungen auch in Zuordnung" bedeutet (unsere Lesart wurde
gestrichen, eine andere nicht genannt), und die Liste, wer tatsaechlich
Praktikum, geringfuegige Beschaeftigung oder Altersteilzeit hat.

Neu offen: ob "freiwillig oder unfreiwillig" fuer gewoehnliche Austritte
Pflicht werden soll — was freiwillig ist, bleibt oft leer, und dann traegt
die Fluktuationsauswertung Luecken. Und dass die Uebernahme rueckwirkend
nicht rekonstruierbar ist: in den Daten steht nur der heutige Stand der
Besetzungsart, nicht, wann er sich geaendert hat.
2026-09-17 12:18:12 +02:00
8bb80d3bd2 Der Wiedereintritt oeffnet den Assistenten, vorbefuellt
Aus dem Gespraech vom 17.09.2026. Migration 20260917130000.

Der kleine Dialog fragte Datum und Planstelle und liess alles andere stehen,
wie es beim Austritt war. Nach zwei Jahren Abwesenheit ist das selten noch
richtig — Anschrift, Wochenstunden, Kollektivvertrag, oft auch der Name. Wer
es bemerkte, musste erst wiedereinstellen und danach "Daten aendern"
oeffnen: zwei Vorgaenge fuer einen, und in der Akte stand dann eine
Vertragsaenderung am Tag des Wiedereintritts, die niemand vorgenommen hat.

rehire_employee nimmt jetzt den ganzen Satz entgegen und schreibt ihn in
einer Transaktion. Erst einstellen und dann aendern waeren zwei
Transaktionen, und scheitert die zweite, steht die Person wieder im Dienst —
mit den Daten von damals und ohne dass es jemand merkt.

Jedes Feld mit coalesce: fehlt ein Schluessel, bleibt der bestehende Wert.
Das haelt den schlanken Aufruf am Leben und ist zugleich die Bedingung
dafuer, dass der Assistent nur schickt, was er auch zeigt — Anschrift,
Staatsbuergerschaft und Aufenthaltstitel fragt er naemlich nicht, so wenig
wie bei einer Neueinstellung.

Die Planstelle und das Eintrittsdatum sind bewusst leer: die alte Stelle
kann besetzt oder entfallen sein, und ein vorbelegter Platz, den es so nicht
mehr gibt, waere schlimmer als ein leeres Feld — er sieht nach einer Antwort
aus. Dazu die Pruefungen der Neueinstellung, die hier fehlten: existiert die
Planstelle, gilt sie zum Datum, ist sie frei.

Die Personalnummer steht fest und wird nur gezeigt. Sie zu pruefen faende
zwangslaeufig einen Treffer — die Person selbst — und sperrte das Formular
mit einer Meldung, die stimmt und trotzdem in die Irre fuehrt.

Ein eigenes Bauteil statt eines Schalters im HireWizard: kein Entwurf zu
speichern, keine Angehoerigen anzulegen (die stehen schon in der Akte),
keine Nummer zu pruefen, andere Funktion am Ende. Geteilt werden die
Schritte, und das ist der Teil, der wirklich geteilt gehoert. RehirePanel
ist damit weg.
2026-09-17 12:16:46 +02:00
6ab78d4b27 Uebernahme: extern auf intern ist ein eigenes Ereignis
Aus dem Gespraech vom 17.09.2026. Migrationen 20260917110000 (Enum-Wert)
und 20260917120000 (Logik) — getrennt, weil ein in derselben Transaktion
angelegter Enum-Wert dort noch nicht benutzt werden darf.

Die Besetzungsart (extern/intern) wurde bisher nur bei der Neueinstellung
gesetzt und war danach unerreichbar. Eine Angabe, die mit dem ersten Tag
erstarrt, obwohl gerade ihr Wechsel der Vorgang ist, um den es geht. Sie
steht jetzt in "Daten aendern".

Wechselt sie von Extern auf Intern, entsteht das Ereignis "Uebernahme" — in
der Personalakte und im Protokoll, und im Berichtemanager als Ereignistyp
auswertbar. Der umgekehrte Weg bekommt ausdruecklich keines: eine Uebernahme
zurueckzunehmen gibt es fachlich nicht.

Zwei Eintraege und nicht einer: die Vertragsaenderung haelt fest, dass ein
Feld sich geaendert hat und worauf (und laesst sich darueber zuruecknehmen),
das Ereignis, dass dieser Wechsel eine Uebernahme war. Nur das zweite laesst
sich zaehlen.

Eine auf spaeter datierte Uebernahme erzeugt das Ereignis sofort mit
pending_id, wie die Vertragsaenderung daneben; der Nachtlauf schreibt am
Stichtag nur noch die Spalte. Die Selbstpruefung haelt fest, dass er kein
zweites Ereignis schreibt — sonst staende die Uebernahme doppelt in der Akte
und jede Auswertung zaehlte sie zweimal.

Im Assistenten erscheint das Feld nicht: dort steht die Besetzungsart im
Schritt "Position", und zweimal danach zu fragen waere eine Einladung, zwei
verschiedene Antworten zu geben.
2026-09-17 12:10:50 +02:00
9ded472d25 Freiwillig oder unfreiwillig wird erhoben, nicht abgeleitet
Migration 20260917100000. Ruecknahme einer eigenen Entscheidung, nach der
Erklaerung des Kunden am 17.09.2026.

Wir hatten den Anstoss aus der Beendigungsart abgeleitet — Kuendigung AN
gilt als freiwillig, Kuendigung AG als unfreiwillig. Das schien sauberer,
weil es zwei Felder ausschliesst, die einander widersprechen koennen.

In Oesterreich stimmt es nicht. Die einvernehmliche Aufloesung ist hier der
Regelfall und sagt ueber den Anstoss nichts aus: sie kann von der Person
ausgehen ("ich moechte kuendigen", worauf einvernehmlich aufgeloest wird,
damit das AMS zahlt) oder vom Dienstgeber ("ich will die Trennung, dafuer
gibt es eine Abfindung"). Dieselbe Beendigungsart, zwei gegensaetzliche
Antworten — und das ist genau die Unterscheidung, auf die es bei einer
Fluktuationsanalyse ankommt. Die Ableitung haette die Haelfte der Faelle
still falsch einsortiert.

Im Formular steht jetzt die Beendigungsart oben mit allen Werten, darunter
"Freiwillig oder unfreiwillig". Keine der beiden schraenkt die andere ein.
Der abgeleitete Hinweis unter der Beendigungsart ist weg — er erschien von
selbst und sah aus wie ein Fehler des Formulars.

Die Angabe ist freiwillig: der Bestand traegt sie nicht, und ein
Befristungsablauf geschieht auf niemandes Betreiben. Ob sie fuer gewoehnliche
Austritte Pflicht werden soll, ist eine Frage an den Kunden.

rehire_employee raeumt sie mit dem Austritt weg. Die Funktion ist dabei
ausgeschrieben worden; die Selbstpruefung haelt fest, dass die beiden
Umstellungen, die sie schon hinter sich hatte (app_current_user_id statt
auth.uid, fester search_path), dabei nicht verlorengehen — genau das ist der
Fehler, den ein create-or-replace aus einer alten Vorlage leise macht.
2026-09-17 12:04:53 +02:00
4165f3f8a1 Der Wiedereintritt war da, nur nicht erreichbar
Aus dem Gespraech vom 17.09.2026.

Der Kunde suchte den Knopf "Wiedereintritt" an einer ausgetretenen Person
und hielt ihn fuer verschwunden — "ich dachte eigentlich, das ist schon
implementiert, das war mal drin". Er war drin. Er hing nur an
employee.status, und diese Spalte haengt nach: an einer Person, deren
Austritt erfasst und inzwischen vollzogen war, stand dort weiter "Aktiv".

Das ist mein Fehler beim Statusfix. Umgestellt waren dort `isActive` und
`canEditData` — die fuenf einzelnen Abfragen in derselben Datei blieben
stehen, dazu je eine in KarenzPanel und TerminatePanel. Jetzt liest keine
mehr die Spalte; die beiden Panels bekommen den abgeleiteten Status
uebergeben, statt ihn sich selbst aus der Zeile zu holen.

Betroffen war ausser dem Wiedereintritt auch: welcher Austritts-Knopf
erscheint ("Nicht angetreten" statt "Austritt"), die Beschriftung der
Abwesenheit, die Vorbelegung der Beendigungsart und ob die Zugehoerigkeit
angezeigt wird.

Dazu: die Niederlassung ist aus dem Reiter Organisation wieder raus. Sie
stand dort als unsere Auslegung von Anforderung 8; der Kunde hat sie im
Gespraech gestrichen ("nimm's mal hier raus"). Was mit der Anforderung
gemeint war, bleibt offen.
2026-09-17 11:50:26 +02:00
bf7f59a959 Ein Raster fuer alle acht Kacheln, nicht drei nebeneinandergestellte
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m24s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m8s
Gleich breit und gleich weit auseinander werden Kacheln erst, wenn sie
demselben Raster angehoeren. Die beiden Anlaeufe davor stellten drei eigene
Raster nebeneinander: zuerst mit gleichem Anteil je Gruppe (fuenf Kacheln
gequetscht, eine mit demselben Platz), dann mit einem Anteil nach
Kachelzahl. Da stimmten die Breiten fast — aber eben nur fast: eine Gruppe
mit fuenf Kacheln hat vier Abstaende in sich, eine mit einer keinen, und
dieser Unterschied verteilt sich auf die Breiten.

Jetzt acht gleiche Spalten und ein einziger Abstandswert. Die Ueberschriften
sitzen in Zeile 1 und ueberspannen die Spalten ihrer Gruppe (5, 2, 1), die
Kacheln in Zeile 2. Beide Zeilen entstehen aus derselben DOM-Reihenfolge —
Ueberschrift, ihre Kacheln, naechste Ueberschrift —, die fuer Vorlesegeraete
die richtige ist; die ausdrueckliche Zeilenangabe sortiert sie fuers Auge.

Die Spannweite steht ausgeschrieben in einer Tabelle und nicht als
span var(--kacheln): Tailwind erzeugt nur Klassen, die als Zeichenkette im
Quelltext stehen, und eine berechnete Spannweite waere zur Bauzeit nicht zu
sehen.

Unterhalb der grossen Breite keine Zeilenangabe: dann fliesst alles der
Reihe nach, Ueberschrift ueber die volle Breite, ihre Kacheln zu zweit
darunter.
2026-09-16 22:54:07 +02:00
c46f18c37a Die acht Kacheln stehen wieder in einer Reihe
Some checks failed
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
CI / Lint, Typen, Tests, Build (push) Has been cancelled
Der erste Anlauf gab jeder Gruppe denselben Anteil der Breite (flex-1).
Damit quetschten sich fuenf Kacheln in ein Drittel und brachen um, waehrend
die einzelne rechts dasselbe Drittel fuer sich hatte — gemeint war eine
Reihe, wie im Entwurf.

Die Breite einer Gruppe folgt jetzt der Zahl ihrer Kacheln. Die Zahl geht
als CSS-Variable in beide Regeln statt als ausgeschriebene Klasse je Gruppe:
kaeme eine neunte Kachel dazu, stimmte die Aufteilung von selbst, waehrend
ein von Hand gesetztes xl:flex-[5] jemand nachziehen muesste — und es fiele
nicht auf, wenn er es vergisst.

Unterhalb der grossen Breite weiterhin untereinander, zwei Kacheln je Reihe:
acht nebeneinander waeren auf einem Laptop unlesbar schmal.

Die Zahl wird in der Reihe kleiner gesetzt. Je Kachel bleiben dort gut
110 px, und "748.4" braucht in 30 px Schriftgrad mehr, als nach dem
Innenabstand uebrig ist — die Kachel hat overflow-hidden, die Zahl waere
also nicht zu breit, sondern abgeschnitten.
2026-09-16 22:47:26 +02:00
e727fac4b7 Der Streifen neben der Bildlaufleiste waren fuenfzig Schatten
Some checks failed
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
CI / Lint, Typen, Tests, Build (push) Has been cancelled
Anmerkung 5, jetzt mit Ursache statt mit Vermutung.

SlideOver bleibt geschlossen im DOM — absichtlich, sonst gaebe es keine
Schiebebewegung. Geschlossen steht das Panel per translate-x-full hinter dem
rechten Bildschirmrand, die eigene linke Kante genau auf dem Rand. Der
Schatten ist das Einzige, was von dort noch ins Bild reicht: 32 px
Weichzeichnung nach aussen, und aussen heisst hier nach links, in die Seite
hinein.

Bei einem Panel faellt das nicht auf. Die Protokollseite rendert aber eines
**je Zeile** — AuditDetail haengt an jeder. Bei fuenfzig Lagen zu 18 %
Deckkraft bleiben rechnerisch 0,01 % Durchsicht: ein fast schwarzer Streifen
neben der Bildlaufleiste, mit Stufen dort, wo sich die Weichzeichnungen der
einzelnen Lagen ueberlagern. Genau das war zu sehen, und genau deshalb nur
auf dieser Seite.

Die Tiefe gehoert zum geoeffneten Panel, nicht zum weggeschobenen. Sie erst
beim Oeffnen zu setzen kostet nichts.

Die Aenderung am Ueberlauf der Tabellenkarten aus dem vorigen Commit bleibt
— sie war eine Aufraeumung, die fuer sich steht, aber nicht die Ursache.
2026-09-16 22:36:37 +02:00
8c8777467c Die Tabellenkarten scrollen nur noch waagrecht
Zu Anmerkung 5 ("In Audit schaut die Scrollbar komisch aus").

`overflow-x-auto` allein genuegt nicht: nach CSS wird eine auf `visible`
stehende Ueberlaufachse auf `auto` hochgestuft, sobald die andere nicht
`visible` ist. Die Karte war damit ein Scrollbereich in beiden Richtungen
und konnte eine senkrechte Leiste zeigen, die nichts bewirkt — die Karte ist
so hoch wie ihr Inhalt, es gibt dort nichts zu scrollen.

Geklemmt wird durch `overflow-y-hidden` nichts, aus demselben Grund. Die
drei Stellen mit diesem Muster sind Protokoll, Mitarbeiterliste und
Importmappe; alle drei sind gleich behandelt.

Ob das *die* Ursache des gemeldeten Bildes ist, ist damit nicht bewiesen —
aus dem Bildschirmfoto allein laesst sich nicht ablesen, zu welchem Element
die zweite Leiste gehoert. Es ist der einzige Scrollbereich auf der Seite
und eine Aufraeumung, die fuer sich steht.
2026-09-16 22:27:22 +02:00
9ad2954970 Anmerkungen vom 16.09.: Uebersicht gegliedert, Personalnummer prueft frueher
1) Die Kacheln stehen jetzt in drei Gruppen — Personalstand,
Personalbewegung, Recruiting & Vakanzen — in der Reihenfolge aus dem Entwurf
des Kunden. Acht Zahlen nebeneinander sind acht Zahlen; sie beantworten aber
drei verschiedene Fragen, und ohne Ueberschrift muss man jede Beschriftung
einzeln lesen, um das herauszufinden. "Aktives Dienstverhaeltnis" steht
vorn: es ist die Bezugsgroesse fast jeder Personalkennzahl.

2) Der Namensfilter in "Anstehend" ist jetzt immer da. Die Schwelle "erst ab
neun Eintraegen" war in der Bedienung falsch — das Feld erschien bei 180
Tagen und verschwand bei 30, und ein Bedienelement, das je nach Zeitraum da
ist oder nicht, wirkt wie ein Fehler.

3b) Der Filter heisst jetzt "Aktives Dienstverhaeltnis (Aktiv +
Langzeitabwesenheit)" — derselbe Name wie die Kachel, die dorthin verlinkt.

6) Die Personalnummer wird gegen die Datenbank geprueft, waehrend sie
eingetippt wird, und nennt bei einem Treffer die Person, die sie schon hat.
hire_employee weist sie weiterhin ab — das bleibt die verbindliche Pruefung,
denn zwischen Frage und Anlegen kann jemand anderes dieselbe Nummer
vergeben. Nur kam diese Abweisung bisher nach sechs Schritten Eingabe, und
das Feld steht im ersten Schritt.

Gemerkt wird dabei die gepruefte *Nummer* samt Ergebnis, nicht ein Ja/Nein:
so ist die Sperre eine Ableitung aus dem, was im Feld steht, und es gibt
keinen Zustand, dessen Zuruecksetzen man vergessen koennte.

Zu 4) geprueft, nichts geaendert: die FTE-Kachel rechnet bereits Summe der
Wochenstunden der heute Aktiven durch 38,5. Der Berichtemanager rechnet
dieselbe Formel, nur als Summe der Einzelquotienten geschrieben.
2026-09-16 22:23:04 +02:00
4dc27bf212 Die Kachel verwies auf eine Adresse, die die Liste nicht lesen konnte
Die neue Kachel "Aktives Dienstverhaeltnis" verlinkte auf
?status=Aktiv&status=Karenz. Die Mitarbeiterliste liest den Parameter aber
als *eine* Zeichenkette und trennt selbst an Kommas — zweimal uebergeben
macht Next daraus ein Array, und `.split(",")` lief dagegen. Sichtbar war
nur "Diese Ansicht konnte nicht geladen werden".

Die Kachel schreibt jetzt status=Aktiv,Karenz. Dazu glaettet die Seite alle
ihre Parameter: eine Adresse kommt nicht nur aus der eigenen Anwendung, sie
steht in Lesezeichen und in E-Mails, und ?q=a&q=b haette sie genauso
gefaellt.

Zwei Anmerkungen von Max:

  * Die Reihenfolge der Wochentage wurde beim Speichern mitgenommen — "Mo,
    Di" und "Di, Mo" waren zwei Werte fuer dieselbe Aussage. Da
    change_employee_data die Arbeitstage als zusammengefuegte Zeichenkette
    vergleicht, erzeugte jedes Nachsehen und Wiederherstellen eine
    Vertragsaenderung in der Akte und einen Protokolleintrag — ueber nichts.
    Jetzt sortiert gespeichert (lib/wochentage.ts, an einer Stelle statt in
    vier Kopien), auch im Massenimport. Der Bestand richtet sich beim
    naechsten Speichern von selbst.
  * "Beguenstigt behindert" steht jetzt als eingerueckter Unterpunkt des
    Kuendigungsschutzes statt als eigener Block daneben. In der Datenbank
    bleiben es getrennte Felder, und das mit Absicht: eine Kopplung liesse
    jede Korrektur am Personenkreis scheitern, solange der Grad noch
    dransteht.
2026-09-16 22:06:38 +02:00
05d56bf3b9 Niederlassung in der Zuordnung, und die Rueckfragen zum Workshop
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m1s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m6s
Anforderung 8. "Zuordnung" liess mehr als eine Lesart zu; umgesetzt ist die,
die am wenigsten voraussetzt: in der Personalakte steht die Niederlassung
jetzt im Reiter Organisation neben Einheit und Kostenstelle. Vorher war sie
nur im Stammdatenblatt zu finden, bei der Privatadresse — dort sucht
niemand den Arbeitsort.

Anders als Einheit und Kostenstelle haengt sie an der Person und nicht an
der Planstelle. Sie steht deshalb auch dann da, wenn es keine laufende
Besetzung gibt.

Dazu docs/rueckfragen-workshop-2026-09.md: sieben Stellen, an denen die
Formulierung mehr als eine Lesart zuliess, mit der jeweils getroffenen
Entscheidung und ihrer Begruendung. Damit bleibt keine Auslegung
unausgesprochen, und jede laesst sich ohne Umbau umdrehen.
2026-09-15 22:58:25 +02:00
b9da3f3411 Planstellen klonen — ausser den leitenden
Anforderung 11 aus dem Workshop. Migration 20260915160000.

In der Fertigung sind Planstellen reihenweise gleich: zwoelf
"Maschinenbediener:in" in derselben Abteilung auf derselben Kostenstelle.
Von Hand angelegt sind das zwoelf Gelegenheiten, die Taetigkeit
unterschiedlich zu schreiben — und ab der zweiten Schreibweise steht sie
zweimal im Katalog und jede Auswertung nach Taetigkeit ist falsch.

Der Klon nimmt Einheit, Taetigkeit (denselben Katalogeintrag) und die zum
Stichtag geltende Kontierung. Nicht mit kommt die Besetzung: eine
Planstelle ist ein Platz, keine Person, der Klon ist frei.

Leitungsplanstellen sind ausgenommen, und zwar mit einer eigenen Meldung.
Je Einheit gibt es genau eine, und ein Unique-Index sichert das ab — ohne
die Pruefung waere ein Klonversuch entweder "duplicate key value violates
unique constraint" oder, mit stillschweigend fallengelassenem is_chief,
eine Planstelle, die anders ist als ihre Vorlage, ohne dass es jemand
angefordert hat. In der Liste fehlt der Knopf dort; das ist Bequemlichkeit,
die Regel steht in der Funktion.
2026-09-15 22:55:33 +02:00
cf0ea51f47 Mitarbeiterart als zweite Achse neben der Beschaeftigtengruppe
Anforderung 9 aus dem Workshop. Migration 20260915140000.

Im Dokument standen die beiden untereinander:

    Arbeiter, Angestellte, Lehrlinge
    Standard / Praktikant / Geringfuegige Beschaeftigung / Altersteilzeit

Die erste Zeile gibt es schon als worker_type, Lehrling seit 20260910140000.
Die zweite ist eine andere Frage: nicht *als was* jemand angestellt ist,
sondern *in welcher Form*. Beide gelten gleichzeitig — ein Praktikant ist
Arbeiter oder Angestellter, nicht statt dessen. In eine Liste gepresst
muesste man sich fuer eine der Antworten entscheiden und verloere die andere.

NOT NULL mit Vorgabe "Standard": jede Person ist in irgendeiner Form
beschaeftigt, und "nicht erfasst" waere keine Aussage, sondern eine Luecke,
die sich durch jede Auswertung zieht. Der Bestand bekommt damit einen
sichtbaren, korrigierbaren Ausgangswert statt eines leeren Feldes.

Die vier Funktionen wurden vollstaendig neu geschrieben. Die Selbstpruefung
haelt deshalb auch die Felder der vorigen Migration fest: eines beim
Uebertragen zu verlieren waere ein Fehler, der nirgends auffiele — die
Oberflaeche schickte den Wert weiter, und die Funktion ignorierte ihn.
2026-09-15 22:52:44 +02:00
c25c16e372 Kuendigungsschutz bekommt einen Personenkreis, die Behinderung eigene Felder
Anforderungen 5 und 5a aus dem Workshop. Migration 20260915120000.

Bisher gab es ein Kennzeichen und ein Enddatum. Das beantwortet "darf hier
ohne Weiteres beendet werden?" — nicht aber, *warum* jemand geschuetzt ist,
und davon haengt ab, wer zustimmen muss. Nachzusehen war das nur im
Papierakt, also dort, wo unter Zeitdruck niemand nachsieht.

Zwoelf Personenkreise als CHECK auf text und nicht als Aufzaehlungstyp: die
Liste ist Rechtslage und aendert sich mit dem Gesetz, ein Typ liesse einen
zurueckgenommenen Wert fuer immer stehen. Die Oberflaeche liest dieselbe
Liste aus lib/kuendigungsschutz.ts; ein Test liest die Migration und haelt
beide gegeneinander, damit die begruendete Doppelung keine stille wird.

Die begueenstigte Behinderung bekommt Kennzeichen, Grad, Beginn und Ende —
vier Spalten und nicht eine zusammengesetzte, weil in Excel danach
gefiltert und summiert wird. Datenbankseitig sind sie *nicht* an den
Personenkreis gekettet: eine solche Bedingung scheiterte genau dann, wenn
jemand den Kreis korrigiert und der Grad noch dransteht. Die Oberflaeche
stellt den Zusammenhang her.

Dazu zwei Dinge, die auf dem Weg auffielen:

  * Der Nachtlauf wendete bei einer auf spaeter datierten Aenderung nur
    Person und Vertrag an — die ganze Gruppe "role" fiel weg. Betriebsrat,
    Dienstwagen, Kollektivvertrag, Arbeitstage, Teilzeit und
    Kuendigungsschutz wurden erfasst, in der Historie vermerkt, protokolliert
    und am Stichtag nicht geschrieben. Sichtbar wurde das nie. Die neuen
    Felder haetten den Fehler geerbt; er ist jetzt fuer alle behoben.
  * Der Mitarbeiter-Export filterte ohne Stichtag ueber die Spalte `status`,
    mit Stichtag ueber die Ableitung. Der Export nach "Ausgetreten" liess
    damit genau die Leute aus, die gerade ausgetreten sind.
2026-09-15 22:47:22 +02:00
8d0c9b4b65 Workshop-Anforderungen, erster Teil: was ohne Migration geht
Anforderung 1 — Freiwilliger vs unfreiwilliger Austritt. Die Liste der
Beendigungsarten zieht aus TerminatePanel.tsx nach lib/beendigung.ts um: der
Berichtemanager braucht sie ebenso, und zwei Listen liefen auseinander. Zwei
neue Arten (Beendigung in der Probezeit, je Seite). Auf wessen Betreiben
beendet wurde, wird aus der Art **abgeleitet** und nicht daneben gespeichert
— als zweites freies Feld liesse sich "Entlassung, freiwillig" erfassen. Das
Dropdown im Formular schraenkt die Auswahl darunter ein.

Drei Gruppen statt zwei: Befristungsablauf geschieht auf niemandes
Betreiben, ein Nichtantritt ist kein Austritt. Beide einer Seite
zuzuschlagen wuerde jede Fluktuationsquote verfaelschen.

Anforderung 2 — Namensfilter in "Anstehend", ab neun Eintraegen.

Anforderung 3 — die zwei Unterschriftenfelder im gedruckten Blatt sind weg;
"Firmenfahrzeug" steht in beiden Checklisten. has_dienstwagen sagt, ob eines
zusteht, nicht ob es uebergeben wurde.

Anforderung 4 — "+794 weitere" ist ein Knopf geworden; die Namen waren
vorher nur ueber den Export erreichbar. Stammdatenaenderung und
Gehaltsanpassung stehen nicht mehr zur Auswahl: die eine entsteht bei jeder
geaenderten Telefonnummer, die andere ist ein totes Ereignis, seit das
Gehalt in Loga liegt. Neu ist der Untertyp — Beendigungsart beim Austritt,
Art der Abwesenheit bei der Langzeitabwesenheit, im Bericht und im Export.

Anforderung 10 — zwei Kacheln. "Aktives Dienstverhaeltnis" ist nicht
dasselbe wie "Aktive Mitarbeiter:innen": dort steht, wer heute arbeitet,
hier, mit wem ein Vertrag laeuft. Sichtbar waren 806 und 10, addieren musste
man selbst.
2026-09-15 22:35:47 +02:00
1cbed1a8f5 Der Status kommt aus den Daten, nicht aus der Spalte
Die Liste filterte ueber die Datumsspalten, beschriftete die Zeilen aber mit
employees.status. Sobald die Spalte nachhaengt, widersprechen sich die
beiden — und sie haengt regelmaessig nach: terminate_employee setzt sie nur,
wenn das Austrittsdatum nicht in der Zukunft liegt, und es gibt keinen Lauf,
der das spaeter nachzieht (Migration 20260814100000 sagt das selbst).

Beim Kunden waren beide Richtungen zu sehen. Der Filter "Ausgetreten" fand
48 Personen, von denen mehrere als "Aktiv" beschriftet waren; der Filter
"Geplant" zeigte Nichtantritte, deren Spalte laengst "Ausgetreten" trug.

StatusChip nimmt deshalb jetzt die Zeile und den Stichtag und leitet selbst
ab. Die Spalte laesst sich nicht mehr hineinreichen — die zweite Quelle ist
nicht bloss ungenutzt, es gibt sie an dieser Stelle nicht mehr.

Dazu drei Stellen, die an derselben Spalte hingen:

  * Die Akte entschied mit ihr ueber die Knoepfe. An einer Person, die seit
    zwei Wochen ausgetreten ist, stand "Austritt" weiter zur Verfuegung.
  * Die Sortierung nach Status ordnete nach einem Wert, der nirgends auf der
    Seite steht.
  * Die Karte "Anstehend" zaehlte kuenftige Eintritte und Rueckkehren ueber
    die Spalte und damit anders als die Liste, auf die sie verlinkt.

Und eine Klausel, die in der Ableitung fehlte: ein Nichtantritt traegt als
Austrittsdatum den Eintrittstag. Liegt der in der Zukunft, ist auch der
Austritt groesser als der Stichtag — die vorige Korrektur verglich nur gegen
den Stichtag und blieb damit wirkungslos. Endet ein Verhaeltnis nicht
spaeter, als es beginnt, gab es keinen Tag Beschaeftigung, zu keinem
Stichtag.
2026-09-15 22:16:30 +02:00
7a33e493b5 Die Historie bekommt ihre eigenen Farben
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 10m59s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m0s
In "Letzte Aktivitaeten" stand "Eintritt" weiter auf Rosa, waehrend die Karte
daneben ihn laengst gruen zeigte. Dieselbe Ursache wie bei den
Anstehend-Chips, nur eine Ecke weiter: die Uebersicht zeigt Ereignisse aus
employee_history, holte ihre Farbe aber aus ACTION_CATEGORY — und das ist die
Sprache des Protokolls. Dort heisst es "Neueinstellung" und
"Wiedereinstellung", in der Historie "Eintritt" und "Wiedereintritt". Genau
diese zwei von elf standen nicht darin und fielen auf den neutralen Chip
zurueck; die uebrigen neun trafen zufaellig.

EVENT_CATEGORY ist jetzt die Zuordnung fuer die Historie, als
Record<HistoryEventType, …> und damit vollzaehlig: ein zwoelftes Ereignis
laesst der Typpruefer nicht durch, ohne dass jemand eine Farbe dafuer
bestimmt. Ein Nachschlagen mit Rueckfall haette auch dann wieder still etwas
Plausibles geliefert.

Betroffen war nicht nur die Uebersicht — der Historie-Reiter in der
Personalakte faerbte seine Chips und seine Filterknoepfe aus derselben
falschen Tabelle. Auch die sind umgestellt.

Die Punkte vor den Zeilen lagen in einer zweiten Tabelle in page.tsx und
sagten fuer "Eintritt" bereits gruen — Punkt und Chip derselben Zeile kamen
also aus zwei Verzeichnissen, von denen eines das falsche war. Beide leiten
jetzt aus EVENT_CATEGORY ab.

Die Rueckkehr ist dabei violett geworden, auch in der Historie: auf der
Uebersicht steht sie neben dem Eintritt, und zwei Gruentoene nebeneinander
sind keine zwei Dinge. ANSTEHEND_STYLES leitet fuer Eintritt, Austritt und
Rueckkehr aus derselben Tabelle ab — die beiden Karten koennen nicht mehr
auseinanderlaufen.

ACTION_CATEGORY behaelt seinen Rueckfall, und das bleibt richtig: die
Aktionen schreiben die SQL-Funktionen als freien Text, eine neue kann
jederzeit dazukommen, und ihr neutraler Chip ist dann eine ehrliche Aussage.
Fuer eine geschlossene Aufzaehlung war derselbe Rueckfall ein Fehler.

Acht Tests, aus EVENT_TYPE_LABELS abgeleitet statt abgeschrieben: dass jedes
Ereignis eine Farbe hat, dass keines den neutralen Chip bekommt, dass Punkt
und Chip derselben Zeile zusammenpassen und dass die beiden Karten der
Uebersicht dasselbe meinen.

Lint, Typen, Schemaabgleich, 575 Tests und der Build sind sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-15 21:48:54 +02:00
a0811d75f4 Das Logo war nie kaputt — der Proxy hat es umgeleitet
Some checks failed
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
CI / Lint, Typen, Tests, Build (push) Has been cancelled
`curl -sI` auf /brand/manner-logo.png antwortete mit **307**. Die Datei lag
die ganze Zeit da, ausgeliefert wurde sie nie: der Abgleich in proxy.ts
nimmt alles ausser _next/static, _next/image und favicon.ico, und public/
stand nicht darin. Eine Anfrage nach dem Logo lief also in den Gate, fand
keine Sitzung und bekam eine Umleitung nach /login. Auf ein <img> antwortet
der Server damit mit HTML, und der Browser zeigt den Ersatztext.

Das erklaert auch, warum es so sprunghaft aussah. Auffallen konnte es nur an
einer einzigen Stelle: die Anmeldeseite ist die einzige Seite, die jemand
ohne Sitzung zu sehen bekommt — und ausgerechnet dort steht das Logo.
Ueberall sonst ist man angemeldet, der Gate laesst das Bild durch. Einmal so
geladen liegt es im Zwischenspeicher und erscheint auf /login weiter, bis
jemand hart neu laedt.

Und es erklaert, warum keine der Aenderungen am Bild geholfen hat: weder das
Ausmisten des SVG noch der Wechsel auf ein PNG konnte etwas ausrichten, weil
die Datei den Browser gar nicht erreichte. Dass es „seit 8016d31" auftrat,
war eine Verwechslung von Ursache und Gelegenheit — dort bekam die
Anmeldeseite ihre rosa Flaeche und damit ueberhaupt erst ein sichtbares Logo
an einer Stelle ohne Sitzung.

Aufgenommen wird jetzt, was eine nicht angemeldete Person auf der
Anmeldeseite braucht: brand/ sowie icon.svg, apple-icon.png und
manifest.webmanifest, die der Browser von sich aus holt. Einzeln aufgezaehlt
und nicht als Regel ueber Dateiendungen — „alles mit einem Punkt darin"
haette auch Routen durchgelassen, die keine Datei sind. In public/ liegt
nichts Personenbezogenes und darf auch nie etwas liegen; alles, was Daten
fuehrt, geht durch withUser() und die Policies.

Fuenf Tests auf den Abgleich selbst. Die vorhandenen rufen proxy()
unmittelbar auf und gehen damit am matcher vorbei — ein Fehler dort war von
ihnen nicht zu sehen. Geprueft wird beides: dass die Dateien vorbeikommen,
und dass sonst nichts aufgeht, auch nicht ueber einen aehnlich aussehenden
Pfad wie /brandneu.

Lint, Typen, Schemaabgleich, 567 Tests und der Build sind sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-15 21:39:58 +02:00
b23ee17608 Logo.tsx wieder vollstaendig machen
Some checks failed
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
CI / Lint, Typen, Tests, Build (push) Has been cancelled
Zwei Handaenderungen hatten das Bauteil halb umgebaut: `aufRosa` war aus der
Signatur von MannerLogo verschwunden, wurde im Rumpf aber weiter benutzt
(erster Build: "Cannot find name"), und nach dem Nachbessern reichte
AppWortmarke die Eigenschaft weiter, die es nicht mehr gab (zweiter Build:
"Property 'aufRosa' does not exist"). Beide Male scheiterte der Typcheck im
Container, und damit blieb der Stand von d2d5e1d unausgeliefert.

Wiederhergestellt ist genau dieser Stand. `aufRosa` wird gebraucht: auf einer
rosa Flaeche darf das Logo kein eigenes Feld bekommen, sonst liegt wieder ein
Rechteck darauf — auf dem Panel der Anmeldeseite waere es das Raster, das
unter dem Feld endet.

Lint, Typen, Schemaabgleich, 562 Tests und der Build sind sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-15 21:30:03 +02:00
0fbafa9b95 Update Logo component 2
Some checks failed
CI / Lint, Typen, Tests, Build (push) Failing after 5m35s
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
2026-09-15 21:17:00 +02:00
76009d6db6 Update Logo component
Some checks failed
CI / Lint, Typen, Tests, Build (push) Failing after 5m27s
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
2026-09-15 21:10:49 +02:00
d2d5e1dabb Drei Befunde aus dem Test: Logo, Geplant-Filter, Anstehend-Farben
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m27s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m2s
**Das Logo auf der Anmeldeseite.** Statt des Schriftzugs stand dort der
Ersatztext "Manner". Die SVG-Fassung war gueltiges XML, lag im Repository und
war committet — warum sie im Betrieb nicht geladen wurde, laesst sich von hier
aus nicht feststellen; dafuer braucht es die Antwort des Servers auf die URL.

Statt das weiter zu raten, faellt die Angriffsflaeche weg: es gibt jetzt eine
Datei, manner-logo.png, der Schriftzug mit durchsichtigem Grund. Kein XML, kein
Beschnitt, kein eingebackenes Feld. Das Blau darin ist #164194, also der Wert
aus §1.1.

Damit verschwinden auch die zwei Fassungen. §1.2 laesst den Schriftzug nur zur
Gaenze auf Rosa zu, und das Manual kennt dafuer zwei Lagen: auf Weiss gehoert
er nach §4.1 in ein rechteckiges rosa Feld, in einem grossflaechigen rosa
Umfeld nach §3.1 nur mit Freiraum. Beides entsteht jetzt aus derselben Datei —
das Feld zeichnet das Bauteil, aus derselben Polsterung wie den Freiraum.

**Der Filter "Geplant" fand Ausgetretene.** Die Ableitung pruefte den Eintritt
vor dem Austritt, und wer einen Eintritt in der Zukunft hatte, galt als
geplant — auch wenn der Austritt laengst verbucht war. Das trifft genau den
No-Show (Migration 20260814100000): eingestellt, nie erschienen, Austritt vor
dem Eintrittstag. Im Bestand sind das Zeilen mit Eintritt 01.10.2026, die der
Filter mitzaehlte, waehrend die Liste daneben "Ausgetreten" anzeigte.
employees.status, das die SQL-Funktion beim Austritt setzt, sagte von Anfang
an das Richtige; falsch war die Ableitung in der Anwendung.

Ein abgeschlossener Austritt wird jetzt zuerst geprueft: er beendet das
Verhaeltnis, gleichgueltig ob der Eintritt schon war oder noch kommt. Ein
Austritt, der selbst noch bevorsteht, nimmt den Eintritt nicht zurueck — wer
am 01.10. anfaengt und am 31.12. aufhoert, ist heute geplant. Die SQL-Fassung
in lib/employee-status-filter.ts bildet dieselbe Reihenfolge ab.

Keine Migration: beide Fassungen der Regel liegen in TypeScript. In SQL wird
nur der Karenz-Teil wiederholt, fuer die Fuehrungslinie, und der ist nicht
betroffen.

**Die vier Anstehend-Chips.** Zwei davon standen in der Markenfarbe, weil die
Farbe ueber den Beschriftungstext aus der Tabelle der Protokoll-Aktionen
geholt wurde — und die kennt eine andere Sprache: "Neueinstellung", nicht
"Eintritt". Wer dort nicht steht, bekam den neutralen Chip. Ein Nachschlagen,
das bei einem Fehlschlag still etwas Plausibles liefert, faellt eben nicht auf.

Die vier haben jetzt eine eigene Zuordnung, nach dem Wert verschluesselt und
nicht nach der Beschriftung: Eintritt gruen, Austritt rot, Wiedervorlage gelb,
Rueckkehr violett. Tuerkis waere fuer die Rueckkehr die naheliegendere Lesart
gewesen, kam gegen das Gruen des Eintritts aber nur auf dE 13.0; Violett steht
mit 30.8 eindeutig daneben. Schwaechstes Paar der vier: 14.2, schwaechster
Kontrast 5.49:1.

Zehn Tests dazu, darunter die drei Faelle, an denen der Filter gescheitert war.

Lint, Typen, Schemaabgleich, 562 Tests und der Build sind sauber. Im Browser
nicht gesehen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-15 20:42:42 +02:00
8016d317be Das Logo ohne Feld auf Rosa, und kein Schwarz mehr auf der Marke
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m16s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m15s
Zwei Dinge, die beim Ansehen aufgefallen sind.

**Das Rechteck auf dem Panel.** Das Logo bringt sein rosa Feld selbst mit, und
auf der rosa Flaeche stand es als Rechteck in leicht anderem Ton darauf. Der
Ton war dabei derselbe — verschoben hat ihn die Lichtblende, die ueber der
Panelflaeche liegt und unter dem Logo endete.

Das Manual kennt fuer den Schriftzug zwei Faelle, und sie brauchen
verschiedene Dateien: auf Weiss gehoert er nach §4.1 in ein rechteckiges rosa
Feld, in einem grossflaechigen rosa Umfeld dagegen wird er nach §3.1 nur mit
Freiraum integriert — die Flaeche ist ja schon da. Es gibt deshalb jetzt
manner-logo-auf-rosa.svg ohne eigenes Feld, und die rosa Flaechen benutzen es.
Damit bleibt nichts mehr uebrig, wo die Blende enden koennte.

Die Blende selbst ist weg. Sie war Weiss auf Rosa und hellte die Markenfarbe
so weit auf, dass sie kaum noch die Markenfarbe war; geblieben ist ein feines
Raster und eine leichte Tiefe zur unteren Ecke, beides aus ink.

**Schwarz auf der Marke.** "Uebersicht", "Berichte" und der Rest der Kopfzeile
standen in ink. Das traegt zwar (7.47:1), sieht aber aus wie Text, der aus
Versehen auf der Marke gelandet ist. Alles Geschriebene auf Rosa steht jetzt
in brand-700: 6.60:1, und es ist dieselbe Paarung, aus der der Schriftzug
selbst besteht — blaue Lettern auf rosa Feld.

Dabei noch eine Schwaeche gefunden: das Abzeichen an der Glocke kam als
danger-solid auf dem rosa Band nur auf 2.78:1 und blieb unter den 3:1, die
WCAG 1.4.11 fuer ein bedeutungstragendes Element verlangt. Mit danger-text
sind es 3.26:1, und die Ziffer darin steht mit 7.12:1 besser als vorher.

**Und ausgemistet.** Die Logodatei wog 74 kB, weil die Vorlage aus Seite 3 des
Manuals gezogen wurde und die ganze Seite mitgenommen hat: 219 Elemente, die
den Fliesstext jener Seite zeichnen ("Der Manner Schriftzug ... darf nicht
veraendert werden"), unsichtbar rosa auf Rosa oder ausserhalb des Beschnitts.
Das eigentliche Logo sind vier Pfade. Beide Fassungen wiegen jetzt 18,7 kB.

Lint, Typen, Schemaabgleich, 552 Tests und der Build sind sauber. Im Browser
nicht gesehen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-14 23:44:01 +02:00
3987e8f54f Rosa fuehrt, Blau bedient
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m1s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m1s
Die Flaechenverteilung war verkehrt herum. Blau lag auf dem Groessten, was die
Anmeldeseite zu vergeben hat, und Rosa nur in Andeutungen daneben — bei einer
Marke, deren Schriftzug auf Rosa steht und deren Manual Rosa zuerst nennt.

Sichtbar wurde es am Logo. Es bringt sein rosa Feld selbst mit, weil §1.2 den
Schriftzug nur zur Gaenze auf Rosa zulaesst. Auf einer blauen Flaeche steht
dieses Feld als ausgeschnittenes Rechteck darauf. Auf Weiss ist es dagegen
richtig — §4.1 verlangt fuer weissen Untergrund genau das, ein rechteckiges
rosa Feld. Falsch war also nicht das Logo, sondern die blaue Flaeche darunter.

Rosa bekommen jetzt: das Panel der Anmeldeseite und das Band ueber der
Anwendung aus Kopfzeile und Logokopf der Seitenleiste. Beide zusammen sind ein
durchgehender Streifen, in dem das Logo aufgeht statt darauf zu liegen — was
§3.1 mit "in einem grossflaechigen rosa Umfeld eingebettet" meint.

Blau bleibt, was es ist: Knopf, Link, Fokusring, ausgewaehlter Eintrag. Das ist
dasselbe Verhaeltnis, aus dem der Schriftzug besteht — blaue Lettern auf rosa
Feld — und es ist das einzige, das traegt. Weiss auf Rosa sind 2.18:1.

Auf den rosa Flaechen steht deshalb nichts Weisses und nichts Gedaempftes mehr.
ink kommt auf 7.47:1, brand-700 auf 6.60:1; ink-muted lag bei 2.33:1 und ist
aus Kopfzeile, Glocke und Logokopf verschwunden. Gestuft wird ueber Groesse und
Gewicht statt ueber Transparenz — eine aufgehellte Schrift ist genau das, was
auf dieser Flaeche durchfaellt.

Das Raster auf dem Panel ist von Weiss auf ink gewechselt: auf Rosa war es
nicht mehr zu sehen.

Lint, Typen, Schemaabgleich, 552 Tests und der Build sind sauber. Im Browser
nicht gesehen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-14 19:47:26 +02:00
f7a5c48615 Die Oberflaeche auf das Manner-CD umstellen
Some checks failed
CI / Lint, Typen, Tests, Build (push) Successful in 11m45s
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
Farben, Schrift, Logo und Symbole folgen jetzt dem CD Manual 2022. An der
Logik aendert sich nichts: keine Migration, keine Abfrage, keine Berechtigung.

Die zwei Markenfarben stehen in §1.1 als #F69686 (Rosa) und #164194 (Blau).
Welche davon was traegt, ist nicht gewaehlt, sondern nachgerechnet: Weiss auf
Rosa kommt auf 2.18:1 und faellt damit auch fuer Grossschrift durch, Blau auf
Rosa auf 4.34:1 und reicht fuer das Logo, nicht fuer Text. Schwarz auf Rosa
sind 7.47:1, Weiss auf Blau 9.47:1. Rosa ist deshalb Flaeche, Blau ist
Interaktion — zwei Skalen, brand-* und accent-*, statt einer geteilten.

Von den 26 Stellen mit brand-50/100/200 sind nur sieben auf accent gewandert.
Der Rest meint einen Zustand und keinen Markenton: die Zeile unter dem Zeiger,
der gewaehlte Listeneintrag, der aktive Menuepunkt. Gegen die warme
Seitenflaeche ist ein kuehler Ton dort deutlicher, und Blau heisst in dieser
Oberflaeche ab jetzt "reagiert auf dich". Nach accent gingen die Faelle ohne
eigene Bedeutung — "Geplant", "Offen", der neutrale Protokoll-Chip — und die
offene Planstelle im Organigramm, die vorher ein blasses Blau war und damit
wie eine schwaechere Person aussah.

Die Funktionsfarben bleiben, was sie sind. Das Manual regelt die Identitaet,
nicht die Rueckmeldung: Rot heisst Fehler, weil die Benutzerin das mitbringt.
`info` bleibt bewusst tuerkis — Blau saehe ab jetzt bedienbar aus, und gemessen
kaeme ein blaues info dem violetten Chip auf dE 6.8 nahe, also nicht
unterscheidbar. Violett ist dabei nachgezogen: gegen den Fehler-Chip stand es
bei dE 8.0, "Austritt" und "Befoerderung" waren im Vorbeigehen dieselbe blasse
Flaeche. Jetzt dE 15.0.

Die Schrift ist Barlow. Nachgezaehlt ist das Manual zu 95 % in DIN gesetzt
(Regular 79 %, Bold 16 %); Helvetica Neue steht nur in den Visitenkarten und im
Claim. DIN laesst sich nicht ausliefern — eine Drucklizenz deckt keinen Webfont
—, und die freien Nachbauten der DIN 1451 sind Schilderschriften, bei 14 px in
einer langen Tabelle schlechter lesbar als das, was sie ersetzen. Die Variable
heisst --font-din und nicht --font-barlow: liegt eines Tages eine Web-Lizenz
vor, ist der Wechsel diese eine Deklaration.

Nebenbei zwei Dinge repariert, die vorher schon falsch waren. Die Umrandung von
Eingabefeldern, Knoepfen und Suchfeldern lag bei 1.30:1 und damit unter den 3:1,
die WCAG 1.4.11 fuer Bedienelemente verlangt; border-strong bringt 3.56:1. Und
das mitgelieferte favicon.ico liess sich gar nicht bauen: eingebettet waren
24-Bit-RGB-PNG, waehrend der Kopf 32 bpp behauptete. Alle Rastersymbole liegen
jetzt als RGBA vor, und ihr Blau ist auf den CD-Wert gezogen — samt der
kantengeglaetteten Raender, indem je Pixel der Blauanteil bestimmt und neu
gemischt wurde.

Das Logo ist das Markenlogo (§4.1), nicht das Unternehmenslogo, das §3.2 fuer
eine Anwendung mit der AG als Absender vorsaehe — es liegt nicht vor. Der
Freiraum X/3 steckt im Bauteil selbst und nicht in den Aufrufstellen, sonst
haengt seine Einhaltung daran, dass jede einzelne daran denkt.

docs/farbschema.html zeigt Token, Kontraste und Bauteile nebeneinander und
laesst sich ohne Server oeffnen.

Nicht im Browser gesehen: Anmeldung laeuft ueber das Firmenkonto und die
Datenbank ist von hier nicht erreichbar. Lint, Typen, Schemaabgleich, 524 Tests
und der Build sind sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-14 19:26:21 +02:00
99e4357c02 Let colleagues finish each other's drafts, one at a time
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m18s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m45s
Seeing a colleague's draft turned out to be half a feature: the point of
sharing it is to finish it while they are away. So writing is allowed
now -- but never by two people at once.

A draft is a single JSONB field. Whoever saves writes the whole state,
not the changed field, so two open wizards overwrite each other
completely and the second person sees nothing wrong: their own state is
right there on screen. That is why writing stayed with the owner until
now, and a lock is what makes giving that up safe.

The lock lives in the row (locked_by, locked_at) and is enforced by the
update and delete policies, not by the application. It expires, and that
is the important half: releasing happens when the wizard closes, and a
closed laptop never closes a wizard. Without expiry one crashed tab
would take a draft away for good -- worse than the problem being solved.
The wizard refreshes its lock while open so a long form does not lose it
mid-way.

Delete had to widen too, which reads like more than was asked for: the
wizard deletes the draft once the person is hired. Without it the hire
would go through and the draft would sit there forever. The card still
only offers delete on your own drafts.

Four of five mutations against the lock go red. The fifth -- dropping
`!open` from the refresh guard -- does not, because freigeben() already
nulls the ref the interval checks. The condition stays as the readable
statement of intent, now with a comment saying so.

Not run against a live database here; the CI migration job is the first
real execution.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-10 17:43:43 +02:00
f17d299045 Lehrling, and a field that stops being named after its values
Some checks failed
CI / Lint, Typen, Tests, Build (push) Successful in 10m51s
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
worker_type had two values because the field was named after them:
"Angestellte:r / Arbeiter:in". Lehrlinge are the third social-insurance
category in Austria; until now they were filed as one of the other two,
which they are not -- and which skewed every report grouped by this
column by exactly those people.

Adding the value is one line. The label was the work: the field was
called after its two values in six places, and each of them becomes
wrong with a third. They now read "Beschaeftigtengruppe", the name the
import has used all along.

One label deliberately keeps the old wording: app_feld_karte() in the
database. That string is not a caption there but a key -- stored rows in
employee_history and pending_changes carry it, and the map is how
reverting or correcting a history entry finds the field again. Renaming
it without rewriting those rows would make every older entry for this
field unrevertable, and nobody would notice until they tried.

The migration's assertion reads pg_enum rather than comparing against
'Lehrling'::worker_type: migrations run inside a transaction, and
Postgres refuses to use a freshly added enum value in the transaction
that added it. This has not been run against a live database here -- the
CI migration job is the first real execution.

Three hand-kept lists of the same enum (reports, import, the form) now
have a test holding them to one another, each mutation-checked.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-10 17:28:49 +02:00
2838919e42 @
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m12s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m6s
Name every draft, and put Vertrag before Angehoerige

Two things the dashboard and the hire wizard were getting wrong.

The drafts card named the author only on other people's drafts. With
foreign and own rows side by side that reads as an inconsistency, not as
information: the eye has to work out that a missing name means "mine".
Now every row says it, "von mir" on the own ones -- the same wording the
notes in the bell already use.

In the wizard, Angehoerige stood before Vertrag. What a contract is made
of -- entry date, working days, a fixed term -- is on paper before the
conversation happens; relatives the person brings along, often on the
first day. The optional step came before the one the hire rests on.

Swapping them meant touching the part that would have broken silently:
the per-step validation was a positional list that had to line up with
STEP_LABELS by hand. Reordered labels alone would have left the checks
where they were -- "Weiter" on Vertrag would have validated the
relatives and waved an empty entry date through, until the database
refused it at the end. The checks are keyed by step name now, so they
travel with the step.

Drafts saved before this land on the step number they stored, which now
points at a different page. Nothing is lost -- the payload carries every
field -- but somebody resuming an older draft may open on Vertrag where
they left Angehoerige.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@
2026-09-10 16:35:20 +02:00
eeaf210e78 Let the same choice open notes and drafts
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m47s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m10s
The picker in the bell now governs both lists, so note_subscriptions is
renamed to colleague_subscriptions -- a name that only mentions notes would
mislead the next reader.

Reading and writing a draft now reach differently far. hire_drafts_owner
(for all) is split into four policies: select lets in your own drafts and
those of the people you added, while insert/update/delete stay with the
owner. A draft is unfinished work with no lock and no history; two people
writing into the same row would overwrite each other silently.

That split forces a change in the actions: a policy does not reject a write,
it lets it hit no rows. saveHireDraft and deleteHireDraft now read the row
count instead of reporting success over a row that never changed.

The card shows a foreign draft with its author and without Fortsetzen or
Loeschen -- offering a button that reliably ends in a database error is a
promise without cover.

check-schema-types.mjs learns `alter table ... rename to`; without it the
drift check reports one rename as two errors.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-10 16:05:40 +02:00
e8e675fd07 Turn the note filter around: yours by default, colleagues added
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m36s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m10s
Yesterday's version had it the other way — everyone visible, untick to
hide. The decision from the business side is the opposite: you see your
own notes, and you tick the colleagues you also want. So note_mutes
becomes note_subscriptions and the predicate flips from `not exists` to
`exists`.

The existing rows are not carried over. The meaning inverts rather than
the sign: converting faithfully ("everyone except the muted") would write
almost the whole roster into the new table and reproduce exactly the state
the change is meant to end. Anyone opening the setting tomorrow would
think it had not taken effect. The table is a day old; what is lost is a
few ticks from trying it out.

What this costs is worth saying plainly: the silent case that could not
happen under exceptions can happen now. Do not tick a colleague and you
will not see her follow-ups — not while she is on holiday either. That is
the flip side of the decision, and it is written down in the migration
rather than discovered later.

Each note now says who wrote it. Own notes read "von mir" rather than
repeating your own name, which would sit on every second line and tell
nobody anything. The flag is computed on the server: the user id is
already there, and threading it through four components for one word is a
poor trade. The counter on the button follows the same turn — "+2" for
what you added, nothing when you added nothing.

Verified: 21 tests, five mutation-checked (restoring `not exists`,
dropping the own-notes clause, inverting the default, hiding the author,
and printing your own name instead of "von mir" each turn them red). 489
tests, typecheck, lint, schema drift and build clean. The migration is
reviewed but not run — no reachable database here.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-10 11:36:38 +02:00
6903013548 Link statt a-Element, und check deckt ab, was der CI prueft
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m12s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m6s
2026-09-10 10:01:08 +02:00
eb25369d1d Let the truncated Anstehend list open
Some checks failed
CI / Lint, Typen, Tests, Build (push) Failing after 5m35s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m14s
"… und 5 weitere Ereignisse in diesem Zeitraum" was a sentence to read.
It is now a button: click it and the rest unfolds in place, click again
and the card goes back to eight rows.

Until now the only way to see the remaining entries was to narrow the
period or the kinds — which changes the question rather than the answer.

This happens in the browser, not through the URL, unlike the period and
kind filters. Those go through the address because a longer period brings
rows into play that were never loaded; here every entry in the period is
already on the page and the eight was purely presentational. A round trip
would mean waiting for data that is already there, plus a history entry
for something nobody wants to go back to.

The list moved into its own component so the state has somewhere to live.
KIND_LABEL and the item type moved with it, since they only describe this
list.

The button only appears when there is something to unfold, and once open
it offers the way back — otherwise the card stays long for the rest of the
session because somebody looked once.

Verified: 10 tests, five mutation-checked (ignoring the state, dropping
the way back, showing the button with nothing to unfold, losing the
singular, dropping aria-expanded each turn them red). 487 tests,
typecheck and build clean. Not seen in a browser — login goes through the
company account and the database is unreachable.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-09 20:20:19 +02:00
99b1df9735 Choose whose notes reach your bell
Some checks failed
CI / Lint, Typen, Tests, Build (push) Failing after 5m49s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m24s
The bell is a shared pile: every active HR person sees every open note,
regardless of who wrote it. That was agreed and it stays the default —
this narrows it, it never widens it. You can now untick colleagues whose
notes you do not want to see.

What gets stored is the *exceptions*, not the selection. The difference
shows the day someone new joins HR: had the selection been stored, she
would be invisible to everyone until each person ticked her, and nobody
would notice her follow-ups piling up. This way she is visible from day
one and hiding her is a deliberate act. Same reasoning that made notes a
shared inbox in the first place — the silent gap is worse than a row too
many.

Own notes always come through: `note_mutes` rejects a self-reference, and
the predicate says so again rather than depending on a check constraint
staying put. Notes with no author come through too — hiding one because
nobody knows who wrote it is exactly the loss this list exists to prevent.

The rule lives in lib/notes.ts as one SQL expression because two places
need it: the bell in the header and the "Anstehend" card on the dashboard.
Two copies drift, and then the card counts something the bell does not
show.

No SQL function and no audit row, unlike anything that touches employee
data — this is a personal display preference, and an audit trail recording
every tick would make finding real changes harder. Same pattern as saved
reports and hire drafts, and the owner policy on note_mutes means a row
for someone else cannot be written even with invented values.

The checkbox flips immediately and flips back if saving fails; the list
gets clicked through several at a time and a round trip per tick feels
like hesitation.

Verified: 19 tests, five mutation-checked (or→and, dropping the own-notes
clause, inverting `not exists`, inverting the default, and losing the
email fallback each turn them red). Typecheck, lint, schema drift, 477
tests and the build are clean. Not seen in a browser: login goes through
the company account and the database is unreachable — the migration is
reviewed but has not been run.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-09 20:03:24 +02:00
e1b69fb022 Festes Enddatum des Passwortpfads zuruecknehmen
Some checks failed
CI / Lint, Typen, Tests, Build (push) Failing after 5m38s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m7s
2026-09-08 17:25:32 +02:00
c6cff9656e Passwort-Anmeldung: Provider, Formulare, drei Zustaende der Shell
Some checks failed
CI / Lint, Typen, Tests, Build (push) Failing after 5m27s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m3s
2026-09-08 16:51:14 +02:00
cbde8cf3a8 Passwort-Anmeldung neben Entra, mit Enddatum im Schema
Some checks failed
CI / Lint, Typen, Tests, Build (push) Successful in 10m52s
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
2026-09-08 16:32:58 +02:00
206a7c6eba Zeilenschutz auf vier Tabellen nachziehen, und den Zustand pruefen
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m36s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m6s
Beim Neuaufbau der Datenbank aus den Migrationen am 26.08. blieben
cost_centers, position_cost_centers, onboarding_tasks und
offboarding_tasks ohne Row Level Security: sie verlassen sich auf
den Ereignis-Trigger ensure_rls, den eine spaetere Migration erst
anlegt. Ein Ereignis-Trigger wirkt nur nach vorne.

Die Policies auf diesen Tabellen existieren und wurden nie
ausgewertet — PostgreSQL befragt sie nur bei eingeschaltetem RLS.
In jeder Aufstellung der Policies sah es richtig aus.

Der CI-Job prueft ab jetzt den Zustand nach dem Lauf, nicht nur
dass die Dateien durchlaufen. Genau in diesem Zwischenraum ist der
Fehler durchgekommen.
2026-09-08 15:36:48 +02:00
405d708bc4 Sort from the column headers, all seven of them
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m2s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m9s
The dropdown is gone; each column header is now a link that sorts by that
column, with an arrow showing the direction. Clicking the column already
sorted reverses it; clicking a different one starts ascending again — going
from "Eintritt, newest first" to "Name" should give you names from A, not
inherit the previous direction.

Names sort by surname and then forename, as asked. Both parts reverse
together: turning only the surname would give Z-A across surnames but A-Z
within each one, which is visible immediately among the fifteen Aigner.

Three of the seven columns are not on the employee row. Bereich and Team
hang off the position, Standort off a lookup table, so they are fetched as
correlated subqueries rather than joins. That is not a style preference: the
same filter chain produces the page *and* the count, and a join onto
position_assignments would double every person who has held more than one
position over time — the line above the list would read 1,203 for 867 people.

Bereich is the level below the company, so it needs to walk up from the unit.
No recursion: org_unit_type has exactly four levels, so two hops up cover it.
Everything sorts `nulls last`, otherwise reversing the direction floats every
person without a position or location to the top.

The expressions live in lib/employee-sort.ts rather than in the page so the
generated SQL can be read in a test — the failure mode here is silent, the
list still shows fifteen rows, just the wrong ones. Eighteen tests, and the
rules are mutation-checked: dropping the forename, dropping the id tiebreaker,
dropping `nulls last`, sorting the location by its uuid, and shortening the
Bereich walk each turn them red.

Not seen in a browser: login goes through the company account and the database
is unreachable. Typecheck, lint, 458 tests and the build are clean.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-07 13:33:09 +02:00
029b63009f Den Postgres-Dienst beim Namen nennen, nicht ueber 127.0.0.1
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 10m58s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m5s
Bei GitHub laeuft der Job auf dem Host und erreicht einen Dienst
ueber den durchgereichten Port. Der Gitea-Runner setzt den Job
selbst in einen Container: dort ist 127.0.0.1 der Container selbst,
und dort horcht kein Postgres — 'Connection refused'.

Beide Container haengen im selben Netz, also gilt derselbe Weg wie
in docker-compose.yml: der Dienst wird ueber seinen Namen erreicht.
2026-09-07 10:42:02 +00:00
a2f2f7075e Ohne sudo — im Runner laeuft alles als root
Some checks failed
CI / Lint, Typen, Tests, Build (push) Successful in 10m54s
CI / Migrationen auf leerer Datenbank (push) Failing after 5m24s
Das Abbild des Gitea-Runners ist schlanker als das von GitHub und
bringt kein sudo mit. Es braucht auch keins: der Schritt laeuft
ohnehin als root.
2026-09-07 10:23:20 +00:00
17c7badd16 psql im Runner bereitstellen
Some checks failed
CI / Lint, Typen, Tests, Build (push) Successful in 10m46s
CI / Migrationen auf leerer Datenbank (push) Failing after 5m18s
Der Job 'Migrationen auf leerer Datenbank' brach beim ersten Schritt
ab: 'psql: command not found'. Das Abbild ubuntu-latest bringt keinen
Postgres-Client mit, die Vorbereitung der Datenbank ruft ihn aber —
deshalb lief der Job nie bis zu dem, wofuer es ihn gibt.

Genau diese Pruefung haette die fehlenden Rechte der Anwendungsrolle
gefunden, bevor sie beim Umzug auftraten: auf einer leeren Datenbank
scheiterte die Anwendung mit 'permission denied for table profiles'.
2026-09-07 10:03:42 +00:00
d07dc80780 Datenbank-Abzuege wieder vom Repository fernhalten
Some checks failed
CI / Lint, Typen, Tests, Build (push) Successful in 11m4s
CI / Migrationen auf leerer Datenbank (push) Failing after 5m14s
Beim Aufraeumen fielen zwei Regeln mit heraus, die Abzuege mit
Personendaten ausschlossen. Die Dateien liegen weiterhin auf dem
Server, ein 'git add .' haette sie mitgenommen — 857 Personalakten
mit SV-Nummern, Adressen und Angehoerigen.

Jetzt nach Ort statt nach Namen: /*.sql trifft die Abzuege im
Wurzelverzeichnis, laesst db/migrations aber unberuehrt (fuehrender
Schraegstrich). Damit greift die Regel auch fuer kuenftige Namen.
2026-09-07 09:41:41 +00:00
4ac516daa1 Read the whole ALTER TABLE, not just its first clause
Some checks failed
CI / Lint, Typen, Tests, Build (push) Successful in 11m6s
CI / Migrationen auf leerer Datenbank (push) Failing after 5m24s
The schema/type drift check has been red in CI. It reported seven
discrepancies, and all seven were the checker's own fault.

The migrations put several clauses in one statement:

  alter table employees
    drop column if exists division_id,
    drop column if exists team_id,
    drop column if exists manager_id,
    drop column if exists org_level,
    drop column if exists is_lead;

The old pattern matched `alter table (\w+)\s+drop column (\w+)` as a single
regex, which finds exactly the first clause. So division_id was dropped from
the model and the other four stayed in it — the checker insisted four columns
existed that the OM cutover removed a year ago. The same cut the other way for
`add column`: kuendigungsschutz_bis, teilzeit_bis and aufenthaltstitel_bis are
each the second clause of their statement, so the checker never saw them and
called them typed-but-absent.

Now the statement is collected up to its terminating semicolon — with paren
depth tracked, so a semicolon inside a check constraint does not end it early
— and every clause inside is applied.

Verified by mutation, not by the green result alone: putting an invented
column into types.ts is caught, and reverting the parser to read only the
first clause brings back exactly those seven messages. That is the diagnosis
confirmed, not merely a passing run.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-07 10:53:57 +02:00
b87c8ad64c Remove Supabase
Some checks failed
CI / Lint, Typen, Tests, Build (push) Failing after 5m40s
CI / Migrationen auf leerer Datenbank (push) Has been cancelled
The database moved to a container of our own; the platform is gone.
This takes out what was left of it — and, where the leftovers were load
bearing, moves rather than deletes.

Moved, not deleted:

  supabase/migrations/  -> db/migrations/      the schema's source of truth
  supabase/build-org.ts -> scripts/build-org.ts
  lib/supabase/types.ts -> lib/types.ts        52 import sites repointed

The bookkeeping needed care. It lived in `supabase_migrations.schema_migrations`,
and simply renaming the schema would have left the runner facing an empty
table: it would have called all 67 migrations pending and replayed them
against a database that is long since current. So the runner now creates
`migrationen.schema_migrations` and, once, copies the old rows across —
guarded so a second run does nothing and a fresh database skips it entirely.
Only then does migration 20260907100000 drop the old schema.

Deleted: the CLI config, the seed, the historical schema/function dumps
(nothing read them), scripts/umzug-von-supabase.sh (the move is done), and
both Supabase packages plus the CLI. Nothing in the application imported
them — the build now succeeds with no environment variables at all, which
is the proof.

Integration tests: six of them signed in through Supabase Auth and asserted
against the anon key and the service role. That model is gone, so the tests
were not portable — they are deleted. session-context and
employee-status-filter already ran on pg and are untouched; om-reporting is
ported to a direct connection because it guards a real risk (the reporting
line rule exists twice, once in SQL and once in TypeScript).

CI: the integration job started a Supabase stack. It now runs a postgres
service, applies deploy/db-init and every migration to an empty database —
that was the valuable part, and it still holds — then checks that a second
run is a no-op, which is what proves the bookkeeping works.

Docs: security-review.md audited a service-role key, a cookie adapter and
auth.users, none of which exist. Restating findings about removed components
would suggest today's system had been reviewed; it has not. It now records
what was removed and says a fresh review is due. data-model.md was already
marked obsolete and described the pre-OM schema; azure-migration.md was a
plan for a route not taken. Both deleted.

Verified: npm ci, typecheck, lint, 445 tests, build — all clean without the
packages. Integration tests skip cleanly with no database. Migration SQL and
the runner are reviewed but NOT executed: no Docker here, and the old
instance no longer resolves.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-07 10:43:22 +02:00
5c310c3a58 Let the employee list be sorted A-Z or Z-A
Some checks failed
CI / Lint, Typen, Tests, Build (push) Failing after 6m12s
CI / Integrationstests (echtes Postgres) (push) Failing after 5m29s
Sorting lives in the URL, not the browser. The list is built on the
server and fetched a page at a time, so a client-side sort would only
reorder the fifteen rows on screen — with 867 people that promises an
alphabetical list and delivers something else on page 2.

The sort key is the surname, because that is how the column reads:
"Aigner, Manuel", and whoever looks for someone looks under A. Postgres
runs with the Austrian collation, so Ö sorts with O rather than at the
end of the alphabet.

Only the surname reverses. The id stays ascending: it decides nothing
except ties, and it exists to keep the order total across page
boundaries. Reversing it too would still be deterministic but would flip
the fourteen Winklers relative to each other for no reason anyone asked
for.

The select sits in the filter bar rather than in a clickable column
header — a header would suggest it sorts what is on screen.

Verified: compiled SQL is `order by last_name desc, id` for Z-A; the
parse and direction rules are covered by tests that were mutation-checked
(breaking each rule turns them red). Not verified in the browser — the
login goes through the company account, and the Supabase instance no
longer resolves.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-07 10:02:40 +02:00
af947f094d Rechte der Anwendungsrolle als Migration, Traefik-Konfiguration ins Repo
Some checks failed
CI / Lint, Typen, Tests, Build (push) Failing after 6m2s
CI / Integrationstests (echtes Postgres) (push) Failing after 5m22s
Der Umzug in einen eigenen Container hat zwei Luecken aufgedeckt:

1. Die Rechte von alpenwerk_app standen in keiner Migration — sie waren
   auf Supabase von Hand im Dashboard vergeben worden. Auf einer leeren
   Datenbank scheiterte die Anwendung deshalb mit 'permission denied for
   table profiles', bevor die Anmeldeseite erschien.

2. docker-compose.traefik.yml lag nur auf dem Server. Ein frischer Clone
   haette die Anwendung ohne Routing hochgefahren. Zusaetzlich haengt app
   jetzt im Netz 'default', sonst findet es den db-Container nicht.
2026-08-26 10:29:33 +00:00
e958bb5c6b Stop pretending Vercel is an option
Some checks failed
CI / Lint, Typen, Tests, Build (push) Failing after 5m51s
CI / Integrationstests (echtes Postgres) (push) Failing after 5m15s
It was never used. The repository lives on a self-hosted Gitea, which
Vercel's git integration cannot connect to at all — so the documented
route amounted to "mirror to GitHub first", and nobody did.

vercel.json is gone, and with it the branch in next.config.ts that
switched off `output: "standalone"` when the VERCEL variable was
present. That branch was the only functional trace; everything else was
documentation and comments describing a second deployment path that did
not exist.

DEPLOYMENT.md loses its "two supported ways" framing and the whole
Vercel section — about fifty lines. Several statements next to it were
stale for a different reason and are corrected in the same pass: the
outbound-firewall table still listed Supabase's pooler (the database is
a container now, nothing leaves the server), the prerequisites still
demanded an existing Supabase project, and the .env table still asked
for a pooler connection string instead of the two new passwords.

The nightly job is described as what it is — a container in
docker-compose.yml — rather than as a replacement for Vercel Cron.

Migrations keep their references: two comments from July mention Vercel
Cron, and they describe what was true when they were written.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 11:02:40 +02:00
77d9a95f7f Run the database in a container of our own
Some checks failed
CI / Lint, Typen, Tests, Build (push) Failing after 5m25s
CI / Integrationstests (echtes Postgres) (push) Failing after 5m9s
Supabase was only ever the host: the application has talked to PostgreSQL
directly through pg/Kysely for a while. So the move is mostly about
supplying what the platform used to supply.

Proved before building anything. All 65 migrations replay onto an empty
database, and the result matches production exactly — 183 columns, 25
policies, 68 indexes, 84 constraints, identical sets, no diff. The only
function missing from the rebuild turned out to matter, see below.

What the platform supplied, deploy/db-init now does:

  - alpenwerk_app, explicitly NOBYPASSRLS. The whole access model is 21
    RLS policies; a role that bypasses them would leave everything
    working while showing too much, and nobody would notice.
  - pgcrypto and pg_trgm. uuid-ossp was available on Supabase but is
    used nowhere — no column default, no function calls uuid_generate_*.
  - anon, authenticated and service_role as NOLOGIN placeholders. No
    policy names them; they only carry grants the platform handed out,
    and a data dump referencing them would fail to restore without them.
  - A stub `auth` schema. The end state needs none of it — checked: no
    foreign key, no policy, no column default refers to it. The June
    2026 migrations do, and rewriting those would be falsifying history;
    they describe what was true then.

The gap the comparison found: rls_auto_enable() and the ensure_rls event
trigger existed only in the running database, created by hand, in no
migration. That is the net which forces RLS on every newly created
table — the reason a forgotten policy yields an empty table instead of
an open one. A rebuild from migrations would silently not have had it:
everything works, and the next new table is unprotected. Now a migration
(20260819100000), verified by creating a table on the rebuild and
confirming RLS came on by itself.

Data moves separately, via scripts/umzug-von-supabase.sh: schema from
the migrations, then pg_dump --data-only --disable-triggers for the rows.
Without --disable-triggers every foreign key trips over load order. RLS
does not interfere — none of the 19 tables uses FORCE ROW LEVEL
SECURITY, so the owner writes through. The dump is deliberately left on
disk afterwards.

psql and node come from two `tools`-profile services rather than being
installed on the host, so the server needs nothing but Docker. The db
service publishes no port at all — reachable only inside the compose
network.

SUPABASE_DB_URL is renamed MIGRATE_DATABASE_URL, since after this it
describes something else entirely; the old name still works so existing
.env files keep running. Both were exercised, as was the error when
neither is set.

The deploy workflow is set to manual-only. Its preconditions were never
met — no secrets, and whether the job container can reach the host's
Docker daemon is untested — and failing on every push teaches people to
ignore red runs. It also needs updating for the new database service
before it could work at all.

Not verified: none of this has run in an actual container. There is no
Docker daemon on this machine. What is verified is the part that
decides whether it can work — the schema, on a real empty database.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 16:34:08 +02:00
d574d3c9d6 Aim the deploy at the runner that exists
Some checks failed
CI / Lint, Typen, Tests, Build (push) Failing after 5m28s
CI / Integrationstests (echtes Postgres) (push) Failing after 5m11s
Deploy / Migrationen und Container (push) Failing after 4s
The workflow asked for a `self-hosted` label. No runner on the instance
offers one, so the run would have sat in "Waiting" forever — no error, no
message, nothing to notice. The existing global runner elycon-runner-01
offers `docker` and `ubuntu-latest`, so both workflows now ask for
`ubuntu-latest`, the same label ci.yml already used.

That correction exposed a second thing the first version glossed over.
act_runner starts a container per job; mounting the Docker socket into
the *runner* does not put it in the *job*. Whether this job can reach the
host's daemon depends on the runner's config.yaml, which is not visible
from here — and the runner is global, so changing it affects every
repository on the instance, not just this one.

Rather than guess, the workflow now measures it in its first step and
fails with the fix if it cannot: which config lines to add for the
socket, or that SSH is the other way. Without that, the run would have
died three steps later on a message nobody could act on.

Both branches of the check were exercised: docker absent prints the
first message, docker present with no reachable daemon the second.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 16:15:49 +02:00
fc0989debb Deploy from a push, and start keeping track of migrations
Some checks failed
CI / Lint, Typen, Tests, Build (push) Failing after 5m52s
CI / Integrationstests (echtes Postgres) (push) Failing after 5m13s
Deploy / Migrationen und Container (push) Has been cancelled
A push to master now builds and restarts the application on the server:
a Gitea Actions workflow on a self-hosted runner writes .env from the
repository secrets, applies pending migrations, rebuilds the compose
stack against the host's Docker daemon, and waits for the container's
healthcheck before calling the run green. Without that last step a
deploy counts as successful the moment the container *starts*, even if
the app inside it dies immediately.

Switching migrations on automatically turned up something that had to be
fixed first: supabase_migrations.schema_migrations did not exist at all.
Every one of the 65 migrations was unrecorded, because they have been
applied by hand all along. An automatic `db push` would therefore have
replayed all 65 against the live database — initial_schema and the OM
cutover included. The database was checked against a spread of
migrations first (it is at head), then baselined: all 65 recorded as
applied without executing them.

The runner is scripts/migrate.mjs rather than the Supabase CLI. It needs
only `pg`, which the project already ships, instead of downloading a CLI
whose version drifts independently of this repository; and it does one
thing — the missing files, in order, each in its own transaction — where
`db push` also diffs schemas and may do more than that. Bookkeeping goes
in the same table in the same shape the CLI uses, so `supabase db push`
from a workstation still works and still skips what already ran.

The workflow lives in .github/workflows, not .gitea/. Gitea reads
.gitea/workflows and falls back to .github/workflows only when the
former is absent — creating .gitea/ would have silently switched off
ci.yml, with the run simply never appearing.

Verified: both workflow files parse; the secret check names what is
missing and refuses; values starting with "-" or containing "=" survive
being written to .env; and the runner was exercised against the real
database with a throwaway migration — applied once, skipped on a second
run, and on a deliberate syntax error rolled back whole, recording
nothing. Both probes were removed; the count is back to 65.

Not verified: nothing has run on an actual Gitea runner — none is
registered yet. DEPLOYMENT.md §5 covers registering one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 16:00:45 +02:00
19e3170b00 Print a checklist without printing the application around it
Some checks failed
CI / Lint, Typen, Tests, Build (push) Failing after 6m6s
CI / Integrationstests (echtes Postgres) (push) Failing after 5m22s
The checklist gets a print view: one A4 page, header carrying personnel
number, name, date of extract, entry date and position, the items in two
flowing columns so twenty-five fit, and two signature lines at the foot.
It prints the *state*, dated — not a blank form.

The default filename in the save dialog comes from the document title,
which is set to the agreed convention:

  20260818_2884_Aigner-Manuel_Onboarding-Checklist

Surname first, like everywhere else in the application, so a folder of
these sorts by person and within a person by date. Umlauts are resolved
rather than stripped: the naive route (NFKD, then every non-ASCII to a
dash) turns "Müller" into "Mu-ller", because decomposition splits the
umlaut and the diaeresis becomes the dash. "Weiß" needs its own rule —
it has no decomposition and would otherwise vanish.

The reported defect: the printout carried the application's own top bar
— hamburger, bell, "Neueinstellung", sign-out. Those are controls; on
paper they are decoration, and on a checklist filed in a personnel
record, misleading. The rule now sits on AppShell rather than on this
one page, so the org-chart print view — which had the same problem —
gets it too, along with anything printed later. The shell's padding goes
with it: the type area is set by @page on the print page itself, and the
shell's would have been added on top.

The browser's own header line (date, title, URL) is separate — that is a
checkbox in the print dialog, not something CSS can reach.

440 tests pass, including 13 new ones pinning the filename convention.
Not yet seen in a browser.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 20:19:58 +02:00
521e4ecf00 Show the Offboarding tab from the day the exit is recorded, not the day it takes effect
Some checks failed
CI / Lint, Typen, Tests, Build (push) Failing after 6m6s
CI / Integrationstests (echtes Postgres) (push) Failing after 5m26s
The tab was keyed off employee.status === "Ausgetreten", and that stays
wrong for weeks: terminate_employee writes exit_date immediately no
matter how far out the date is, but only flips status once the date
itself arrives. A termination entered today for four weeks out left the
tab invisible for the entire notice period — exactly the stretch in
which IT access, hardware and deregistration actually get worked
through, and exactly where the checklist was supposed to live "next to
Onboarding," per the report that caught this.

The rule now reads exit_date instead: not null, and not a No Show
(which sets exit_date too, to the entry day, but never worked a day and
gets no checklist). rehire_employee resets both exit_date and
exit_reason to null, so a rehired person's tab still disappears the
same way it did before — nothing about that case changed, only the
signal the check reads.

Verified against the real database with the exact shape from the
report: a termination dated 30 days out. Status stays "Aktiv", the
checklist exists immediately, and the tab's own predicate says yes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-17 17:41:07 +02:00
f85731dde5 Give exits their own checklist, next to the entry one
Some checks failed
CI / Lint, Typen, Tests, Build (push) Failing after 5m42s
CI / Integrationstests (echtes Postgres) (push) Failing after 5m35s
The offboarding list was a checkbox fieldset inside the exit panel — four
items, never sent anywhere. Nothing in terminateEmployee's payload
carried them; ticking a box there recorded exactly nothing.

It's replaced with the same kind of list the entries got: its own tab,
appearing the moment an exit is recorded, with one item per row, a
comment on each, and — unlike the fieldset — a record of who touched it
and when.

The eleven items come from the same printed sheet as the entry list.
Nine are plain checkboxes. Two are text fields under "Vermerke":
remaining vacation and the balance transferred for payout — the sheet
names "Überleitung Salden für Auszahlung" twice, once as a task to do
and once as the actual figure, and those are genuinely two different
questions, kept as two items. Where the sheet still says "GKK" rather
than today's "ÖGK", it's left as written — that's the name the process
runs under internally, not a typo.

No Show gets no list. Never having worked a single day, there's no IT
access to revoke, no GKK registration to undo, no Dienstzettel to
collect — an empty checklist there would be a label with nothing behind
it. Both the tab and the auto-creation on exit check for this
specifically, not just the "Ausgetreten" status that No Show shares with
a real exit. Rehiring the same person hides the tab again — the data
stays, since it happened, but a checklist for someone currently working
has nothing to point at.

The engine (what counts as done, how progress is computed) moved into
lib/checklist.ts so onboarding and offboarding can't drift into two
different ideas of "done" the way two independent copies eventually do;
lib/onboarding.ts and lib/offboarding.ts bind it to their own item list,
and the tab UI is a single ChecklistPanel bound the same way.

Checked against the real database: a real exit creates all eleven items
in the same transaction as the exit itself; a No Show creates none;
rehiring flips the tab off while the old answers stay queryable. One
false alarm during that check turned out to be the user's own clicks on
a real employee's onboarding list, made in the browser while trying the
earlier feature — left untouched, not test debris.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-17 16:25:58 +02:00
82d07f0d95 Put the onboarding checklist where the file is
Some checks failed
CI / Lint, Typen, Tests, Build (push) Failing after 6m24s
CI / Integrationstests (echtes Postgres) (push) Failing after 5m51s
The list existed on paper: one printed sheet per entry, twenty-five
boxes. What is on it is known only to whoever holds the sheet — it
cannot be searched, cannot be covered for while someone is away, and
says nothing about who ticked what.

Not every box on the sheet is a checkbox, and the differences carry
meaning, so the field kind is derived from the thing rather than
flattened:

  Haken   — the normal case. The Meldezettel is there or it is not.
  Ja/Nein — Prämienanspruch had *two* boxes on the sheet, and that is
            not decoration: "nein" is a finding, "not asked yet" is not.
            One checkbox cannot say both.
  Text    — shoe, shirt and trouser size. The value is the point;
            ticked off it would be worthless.

Every item takes a comment, and every item records who last touched it
and when — the part the sheet could never do.

Saved on click, not on submit. A checklist is worked through over days,
between other things; a save button at the end is where half a morning
goes missing.

The items live in lib/onboarding.ts, not in a table: a checklist is a
company process, not a master record. Stored per person is only the
answer, under the item's key — so an item dropped later leaves its old
answers standing instead of taking them along, and a file from back then
stays readable.

A list is created by hire and rehire, in the same transaction as the
hire itself: a hire without a checklist would be a half-recorded hire.
Rehire only adds what is missing and never clears an old tick — what
genuinely has to be redone is HR's call, and a program deciding it would
be guessing. People hired before this feature have no list and get a
button to start one.

Checked against the real database end to end: hire creates 25 open
items; checkbox, ja/nein, size and comment all land; a comment-only edit
leaves the tick alone; rehire tops the list up and keeps what was done.
The probe employee was removed afterwards — audit rows first, since the
log has no delete policy.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-17 15:40:02 +02:00
bd990b7f2c Merge branch 'feat/sap-om-org-model'
Some checks failed
CI / Lint, Typen, Tests, Build (push) Failing after 6m9s
CI / Integrationstests (echtes Postgres) (push) Failing after 5m20s
2026-08-17 12:42:38 +02:00
e30923e781 Give a position a cost centre
There was none anywhere in the model, so no personnel-cost figure could
be produced at all, and an open position could not say whose budget it
would charge — which is the first question asked about a vacancy.

It hangs on the position, not on the person: the seat costs money even
when nobody sits on it. That is exactly the vacancy case. And not on the
org unit either, although it usually follows from one — a single seat
can be charged elsewhere (project, shared function) without the unit
moving.

As its own dated assignment table rather than a column, because
reassigning is an event with a date. Last year's costs have to stay
where they were incurred; as a column, every change would silently
rewrite every past report. Half-open [valid_from, valid_to), like
position_assignments and om_positions — in SAP OM this is A011.

25 cost centres seeded from the org tree: one per company, division and
department, with teams charging to their department, because a team is a
span of control and not a budget. All 823 positions were assigned from
their own start date, none left over. The number is the first five digits
of the org number, so it can be traced rather than looked up.

Reassignment refuses three things, each checked: the same cost centre
again, a switch on the day the current one started (that period would
never have been in force, and the range constraint says so), and a date
before the position exists.

Verified against the real data, which turned up a defect worth keeping:
a position that starts in the future is charged only from its start, so
asked about today it had no cost centre — and future positions are
exactly what the vacancy list is for. It is now read at the position's
own start date.

Two audit entries from the probe could not be deleted through the
application (the log has no delete policy — correctly), so I removed
them with the admin connection.

Still open, and the reason this is only the first of the three fields I
proposed: location and planned FTE.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 19:57:09 +02:00
3a4f44318c Derive the filter test's list from the registry it tests
Adding the follow-up kind turned one of these tests green-for-the-wrong-
reason and one red: both had the three kinds written out by hand, so
"all of them are selected" no longer meant what the name said. That is
the failure mode a hand-copied list has — it does not break loudly, it
drifts.

The list now comes from ANSTEHEND_ARTEN, and the two cases that depend
on completeness build their input from it.

I committed the previous change with this test red. That was wrong; it
should have blocked the commit.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 19:46:24 +02:00
10f8f1f2d5 Keep a note on the overview until somebody ticks it off
A note with a follow-up date is a task, and the overview is where tasks
are looked for. Until now it lived only in the employee file, which is
the one place you go when you already know who you are looking for.

Follow-ups behave differently from everything else on that card, and the
difference is the point: an entry on Monday is over on Tuesday, an
unfinished task is not. So there is no lower bound on the date — what
was due and never ticked off stays, marked overdue in red, sorted to the
top because it is sorted by date. A task that drops out of the list by
itself is a forgotten task.

Only "Erledigt" removes it. A note without a follow-up date never
appears: it is a record, not a task.

Checked against the live database — an overdue one and an upcoming one
appear, one without a date and one beyond the chosen period do not, and
ticking the overdue one off removes exactly it. The probe notes were
deleted again.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 19:44:48 +02:00
91b2b3406b Stop waiting on the network eleven times per page
The app got slower as pages grew, and the reason was not the queries. It
was their number.

A transaction is pinned to one connection, and a connection runs queries
one after another. Every Promise.all in a withUser block looked like
concurrency and was a queue. Measured against the real database: the
round trip is ~36 ms, ten trivial `select 1` over one connection take
343 ms, over ten connections 39 ms. Nothing here is slow — the whole
dashboard payload is under 200 kB, and every table is around a thousand
rows.

More connections is the wrong answer: the RLS session context is per
transaction, so parallel reads mean parallel transactions, and those
multiply the connections the database will grant. Fewer round trips
instead. Postgres will return each sub-select as its own JSON column of
one result.

Per page view, counting the transaction frame:

  shell (paid by every page)  10 → 4
  overview                    14 → 5
  employee file               14 → 7
  employee list                8 → 6

The overview plus its shell went from 24 round trips to 9 — about 860 ms
of pure waiting down to about 320 ms.

The one trap is documented where it bites: inside json_agg, Postgres
formats values itself and the driver's parsers (lib/db/pool.ts) never
see them. Dates, numerics and uuids come out identical; timestamptz does
not — "+00:00" where the driver gives "…Z". Timestamps are compared as
strings in lib/history.ts to decide what happened later, and those two
forms sort against each other wrongly. Every timestamptz in a bundled
query therefore goes through zeitstempel(), which was checked
character-for-character against the driver.

Four loaders moved out of their pages into lib/ so the number of round
trips can be measured without building a React tree, and so the new path
could be held against the old one field by field: same rows, same order,
same strings, for the overview and for four employee files chosen to
differ (with history, a chief, a planned entry, one with dependents).

withUser now counts the queries in each transaction and says so in
development past a threshold. Without that, this grows back: each new
tile brings its own query, and nobody notices until everybody does.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 19:31:36 +02:00
6957b95a97 Let the overview say what "upcoming" means
Sixty days and all three kinds was a guess, and it was the only one on
offer. Payroll cares about next month; the person filling a vacancy
cares about entries and nothing else. The card now takes a period and a
set of kinds.

The choice lives in the address rather than in the browser, because it
has to: the page is built on the server, and ninety days pulls in rows
that were never loaded at sixty. Filtering client-side would silently
cap the answer at whatever the first query happened to fetch. It also
means a filtered overview can be sent to someone and opened again the
same way.

Deselecting every kind returns to all of them. An empty card is not an
answer to a question nobody asked, and the way back would otherwise be
one click further than the way in. The default period and the full set
are absent from the URL instead of written into it, so a shared link
carries only what was actually chosen.

Anything the address cannot be trusted to hold is rejected: an unknown
period falls back to sixty rather than reaching the query, which would
otherwise be an invitation to ask for ten years of rows through a link.

Eight rows still, with a count of what did not fit underneath — this is
an overview, and the employee list is where lists belong.

Not verified in a browser: the built-in preview has no company sign-in,
so the page redirects to the login before it renders. Types, lint and
386 tests pass, and the filter's behaviour is covered directly.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 18:56:05 +02:00
16216c5537 Let a planned absence be called off
The old refusal read: "Diese Abwesenheit ist noch nicht wirksam. Sie muss
über den Vorgang selbst abgebrochen werden." There was no such way. The
row sat in the file, the scheduled change kept running toward its date,
and nothing could stop either one.

That is not hypothetical. One person went absent in July, came back in
August, and still has a second return booked for the first of September
— recorded while they were already working again. The guard added
yesterday stops a third from being written; it does not remove the one
that exists.

Absences are called off whole, not field by field. For a planned
contract change the scheduled payload gets the affected fields lifted
out of it and runs on with the rest; an absence has no fields in that
map, and half an absence is not a thing anyone means. So the whole
scheduled change is cancelled, and what it had already noted on the
person goes with it: the date they were to be away from, the date they
were to come back on. Left behind, the profile would show an absence
with no event behind it. If the absence is still running, the return
date planned when it began applies again.

The link between the row and the scheduled change had to exist first —
start_karenz and record_karenz_return now record it. Existing rows get
it backfilled, but only where one running change of that kind falls on
that person and that day. Where two would match, the row keeps refusing:
guessing which process to cancel is worse than refusing to.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-15 11:44:21 +02:00
861c47b757 Correct an entry date, and stop returns without an absence
Three things, all from the same screenshot.

The entry date can now be corrected. The Eintritt entry gets an edit
button — date only, no delete, because it is the start of the timeline
and a person without one has no beginning. Unlike every other entry it
needs no recorded before-values: the old date is on the employee row, so
this works on rows written long before any of this existed, which is
exactly the case that matters.

What hangs off that date is checked: no other event may precede it, exit
and absence start may not fall before it, and the first position
assignment moves with it — left behind it would leave days of employment
with no post, or a post with nobody in it. Someone already working
cannot be given a future entry date either; without that check a person
who has been here for years could be turned into a planned entry, and
the status derivation would agree.

That last rule came out of the rehearsal finding a hole: my first probe
picked a person with no other history rows, so the "nothing may precede
it" check had nothing to compare against and a date in 2099 sailed
through.

Second, the screenshot showed two returns from one absence, and the data
confirmed it: one person with two Rückkehr entries and a third still
scheduled, recorded while they were long since active. record_karenz_
return never checked that there was an absence to return from. Now it
does, and it refuses a second scheduled return — which would have
silently overwritten the first on its effective date.

Third, the history is filterable: upcoming versus done, a date range,
and the event types that actually occur in that file. The count of
upcoming items shows without filtering, because "what is coming" is the
usual reason to open the tab at all.

Still not deletable: Versetzung, Beförderung, Austritt, Wiedereintritt,
Reorganisation. Undoing those means restoring position assignments, and
that deserves its own step rather than being tacked onto this one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-15 11:31:41 +02:00
d2f4a7aab7 Ask for a residence permit only where one is needed
Employees from outside the EU, the EEA and Switzerland need a residence
permit, and HR needs to know when it expires — about eighty people in
the current data, across Türkei, Serbien and Bosnien. Two columns, the
same shape as the dismissal protection: a flag and a date that only
means anything with it. The date is optional, because an open-ended
permit has none and a mandatory field would force an invented one.

The nationality coupling deliberately stays out of the database. Putting
it there would mean keeping the country list in two places — SQL and
lib/countries.ts, where the picker needs it anyway — so an EU accession
would become a migration instead of a line in a list. Worse, correcting
somebody's nationality would fail the constraint while the old permit
was still attached, which is exactly the moment someone is fixing a
mistake. The UI decides whether the fields appear, and clears them when
the nationality moves into the free-movement area.

So the list is the load-bearing part, and it is tested: 31 entries, all
of them values the picker can actually produce, no duplicates, no third
countries. A missing nationality reads as "no permit required" — an
unanswered question is a reason to record it, not to demand papers.

The permit shows on the Stammdaten tab only for the nationalities it
applies to. A line reading "Aufenthaltstitel: Nein" under an Austrian
citizenship would look like information rather than a question that does
not arise.

Filter by it and by when it expires — the question behind that being
"whose permit runs out next quarter" — plus columns in the export.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-14 13:27:26 +02:00
384bdb4fb3 Let an absence be taken back, in the right order
A long-term absence recorded by mistake could only be undone by booking
a second event on top of it — leaving two entries in the file, the first
of which never happened. Karenz and Rückkehr can now be deleted and
corrected like the other entries.

For that to restore anything, the two operations first had to start
recording what they overwrote. start_karenz and record_karenz_return now
keep before/after the way change_employee_data does: status, kind of
absence, start, planned return — and for a return also employment type,
hours and the part-time variant. Without that there is nothing to revert
to, only a sentence.

The ordering rule HR asked for is enforced in the database, not just in
the UI: an absence cannot be deleted while a later return exists. A
return standing on its own would be a return from nothing, and the
person's status would derive from an entry whose starting point had been
deleted. Delete the return first and the absence frees up.

Rehearsed end to end on real data: absence recorded, return recorded on
reduced hours; deleting the absence refused; deleting the return put the
person back on Karenz with the original hours and the part-time variant
cleared; deleting the absence then put them back to Aktiv with no trace.

Rows written before today carry no before/after and stay untouchable,
with the reason they already gave. Planned absences are refused too —
they have their own operation, and their fields have no place in a
pending payload, which is why app_feld_karte carries a null group for
them rather than a plausible-looking wrong one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-14 13:13:01 +02:00
f5ace8af2e Make the part-time arrangement a state you can report on
Last step moved the four part-time arrangements out of the absence list
and recorded the reason in the history text. That answered "what
happened" but not "who is in one right now", and the profile showed
nothing at all. So it becomes a real field: teilzeit_art, with an
optional end date.

The objection I raised then still holds — a state goes stale, because
nobody goes back to note when a Bildungsteilzeit ended. teilzeit_bis is
the answer to it: with an end date a report decides for itself what is
still running instead of trusting that someone maintained the row. Left
empty it means "open end", which is an honest thing to say.

It runs through the ordinary change machinery rather than beside it. It
sits in app_feld_karte, so it shows up in the history as a field with
before and after, and can be corrected there like any other. The
description suffix from last step is gone — writing the same thing twice
is how two versions start disagreeing.

Reporting: filter by variant, by "in one at all", and by when it ends;
group headcount by variant, where the absence of one reads "Keine"
rather than a dash, because in a report that is an answer and not a gap.
Plus columns in the export and the import.

One gap found while rehearsing, and only because the probe happened to
pick a return date in the future: a scheduled return carries its payload
through pending_org_changes, and that payload did not include the
variant. Someone would have come back on reduced hours in April with the
reason gone. The daily run now carries it too.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-14 13:07:41 +02:00
e6554e7982 Move the part-time arrangements out of the absence list
Bildungsteilzeit, Elternteilzeit, Pflegeteilzeit and
Wiedereingliederungsteilzeit were offered as kinds of long-term absence.
Recorded that way, the person counted as absent: they dropped out of
headcount, their reporting line fell to a stand-in, and reports stopped
counting them — while they were in the building every week, just for
fewer hours. A part-time arrangement is not an absence; it is a change
of hours.

They now sit where they belong. Wiedereingliederungs- and Elternteilzeit
appear when recording a return from absence, as the reason someone comes
back on reduced hours — both typically begin exactly when the absence
ends. Bildungs- and Pflegeteilzeit appear under "Daten ändern" beside
the hours, next to the ordinary contractual change.

The reason is recorded with the change, not as a state on the person. A
state would have to be maintained, and nobody goes back to note when a
Bildungsteilzeit ended; a field that quietly goes stale is worse than
none. In the history it stands next to the value it explains, and stays
readable for good.

The check constraint on absence_type is deliberately untouched. Three
people carry the old values right now — two Pflegeteilzeit, one
Wiedereingliederungsteilzeit. Forbidding them would make existing rows
illegal. They are gone from the list of choices; the history stays
readable. Those three are worth revisiting, but that is a data decision,
not a code one.

Rehearsed against real data: an hours change with a reason and one
without, a reduced return with a reason and an unchanged one — checked
by reading both new history rows rather than "the latest", since now()
stands still inside a transaction and made an earlier probe report a
false negative.

I also overwrote tests/unit/absence.test.ts instead of extending it. The
original cases are restored; the diff is 49 added lines and 3 changed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-14 12:56:21 +02:00
6681dcda77 Flag people who cannot simply be dismissed
Works council members, expectant mothers, parents on leave, registered
disabled employees, apprentices — each has its own rules that come
before a dismissal. The tool does not judge whether one is lawful, but
it must not stay quiet about it either, and looking it up on the
contract tab is exactly the step that gets skipped under time pressure.

So: a checkbox, an optional end date, and a red warning at the top of
the termination panel naming the date — or saying plainly that no end
was recorded. It shows for a no-show too; the protection runs from the
start of the contract, not the first day worked.

The date is optional on purpose. A works council mandate has a known
end, a pregnancy does not, and a mandatory field would force an invented
number. A constraint says only what cannot be: an end date without the
flag, which would be a leftover nobody could interpret.

The field goes the whole way through — hire, data change, contract
sheet, export, report criteria (as a yes/no and as a date range), and
the import. A field that exists in one screen and not the next is how
people stop trusting the numbers.

Terminating is now offered for planned entries as well, labelled "Nicht
angetreten", with No Show preselected. Without it a person who never
turned up stayed a planned entry forever, since nothing else can end
one.

One finding worth recording: tsc has been reporting success on a broken
program. A generated file under .next got corrupted when a build ran
against a live dev server, and its syntax errors suppressed semantic
checking everywhere else — two genuine type errors in this change went
unreported until I typechecked with .next excluded. The file is removed
and the ordinary typecheck is meaningful again.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-14 12:44:00 +02:00
0144267a59 Record people who never turned up
Someone hired who then does not start needs an exit reason of its own,
and until now the case could not be recorded at all. Terminating on the
entry date failed on chk_assignment_range: the assignment was closed
with valid_to = valid_from, and an empty interval is forbidden there.
Moving the exit to the next day would have claimed a day of employment
that never happened — headcount, tenure, every as-of report.

"No Show" is now an exit reason, and it behaves differently in three
ways.

The exit date is always the entry date, whatever the caller passed. That
is what makes "never active" true rather than asserted: a person counts
as employed when their exit date is *after* the reporting date, and here
it never is. The status derivation needed no change at all — it already
says Geplant before the entry date and Ausgetreten from it on.

The position assignment is deleted rather than closed. The post was
never filled, it goes back to being open, and nothing records a holder
who never held it.

The status column goes to Ausgetreten immediately, even for an entry
still in the future. Otherwise it would read Geplant forever — nothing
runs later to correct it.

A constraint holds the first of those regardless of the path in,
including the import: exit_reason is distinct from 'No Show' or
exit_date = entry_date. "is distinct from" rather than "<>" so an empty
reason does not evaluate to null and slip through — the same three-
valued trap that let an earlier check pass the case it was written to
stop.

The dialog locks the date field when No Show is picked and says why, so
nobody types a date that would then be silently overridden. The
offboarding checklist is hidden: nothing was ever handed out.

Rehearsed against real data — a planned entry with a 2099 date passed
in, which came back as the entry date; derived status across three
reporting dates never Aktiv; a direct write with a mismatched date
refused; and an ordinary termination unchanged.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-14 12:33:14 +02:00
8a76b3688f Show people surname first
Employee names now read "Winkler, Hannah" wherever a person appears in a
list, a table, a heading or a tree node. That is the order a personnel
list is kept in, it is the order people are looked up in, and it finally
matches the sorting — the employee list has always been ordered by
surname, which made an alphabetical page look unsorted.

The name was being assembled inline in about twenty places. A rename
that catches half of them is worse than none, so it now goes through
fmtName in lib/format.ts and every display site calls it.

Sentences keep the natural order: "Hannah Winkler wurde versetzt" reads
like German, "Winkler, Hannah wurde versetzt" reads like a form. So the
toasts are unchanged and only labels moved.

Two things the change would have quietly broken:

The org chart's own filter matched against "first last". It now matches
either order, with or without the comma, so typing what you see works
and so does typing what you remember.

The print model sorted by the last word of the composed name, which
happened to be the surname and is now the first name — every printed
unit would have come out sorted by first name. It sorts on the surname
field itself now, which is what it meant all along.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-14 11:44:03 +02:00
a3fac47f47 Give each characteristic its own line, and name the car
The contract sheet had one field, "Merkmale", holding whatever applied,
comma-separated — and a dash when nothing did. Two problems in one row.
A dash cannot distinguish "has no company car" from "nobody ever
answered the question", and the entry read "Dienstwagen" without saying
which kind, which is the thing worth knowing since electric vehicles are
tracked separately.

Betriebsrat, Dienstwagen, laterale Führung and C-Level are now four
lines like every other line on the sheet, each with Ja or Nein. The
company car shows its drivetrain instead: E-KFZ or Verbrenner.

That label existed in three places — the dropdown, the hire summary and
now here. It lives in lib/dienstwagen.ts, so the same car cannot end up
named differently depending on which screen you are looking at.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-14 07:06:58 +02:00
08d2740690 Let planned changes be taken back and corrected too
Deleting and correcting a history entry stopped at the present: anything
not yet effective stayed put. That was not a principle, it was a missing
link. A planned change lives as a payload in pending_org_changes, and
nothing tied it to the history row — only a person and a date, and the
data already holds an Eintritt and a Vertragsänderung sharing one. So
employee_history now carries pending_id, set by change_employee_data
when it schedules something.

One planned change can carry two history rows: Stammdaten and Vertrag
are kept apart but scheduled together. Taking one back therefore strips
only that group's fields from the payload, and cancels the operation
only when nothing is left. Correcting one rewrites its group and the
effective date, and touches no employee data — the change has not
happened yet.

An entry stays on its side of the present. Pulling a planned change into
today, or pushing an effective one into the future, would mean adjusting
the employee record and the pending payload in opposite directions;
that is what the real operations are for.

Existing rows were linked where exactly one running operation matched
the person and date and no other row had claimed it. All five of them
matched. Anything ambiguous would have kept the old refusal, which now
says the actual reason.

The edit dialog surfaced a bug in useDialogFocus that predates it: the
effect depended on the identity of onClose, which almost every caller
rebuilds on render, so it re-ran after each keystroke and its cleanup
pulled focus back to whatever opened the dialog. Any dialog with a text
field would have accepted one character. It never showed because until
now no dialog kept its own state next to its own onClose.

Rehearsed against real data: a two-row planned change corrected, one row
taken back with the operation continuing on the rest, the second taken
back with the operation cancelled, and both refusals.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-13 21:35:51 +02:00
9308096754 Search names first, and only fall back to job titles
"Winkler M" returned four people, two of whom are not called M: Karin
Winkler is a Montagemitarbeiterin and Katharina Winkler a
Maschinenbedienerin. The job title was searched with the same weight as
the name, so a single letter matched the start of a job word just as
readily as the start of a first name.

Searching job titles is worth keeping — "dreher" finding the CNC-Dreher
is useful. So the search is now tiered: names alone first, and the job
title joins in only when the names return nothing at all. A minimum word
length would have been the simpler rule, but any threshold is a guess;
this one is decided by the data in front of it.

Checked against the live data: "winkler m" gives Martin and Magdalena,
"winkler h" Hannah, "dreher" and "montage" still find their trades, and
"winkler montage" finds Karin Winkler — no name matches both words, so
the fallback does what was meant.

When the fallback runs, the result line says so. Without that, a list of
people whose names look nothing like the query reads as though the
search invented them.

Costs one small count query, and only when text was typed.

Not verified with next build: a dev server from an earlier session is
holding .next, and the user is testing in it. tsc, eslint and 297 tests
are green, and the search itself was run against the database.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-13 21:13:41 +02:00
33d053ce75 Match search words at the start of a word, not anywhere inside one
Searching "Winkler H" returned all seven Winklers instead of the one
Hannah. Each word was matched as a substring, so "H" hit T-h-omas,
Kat-h-arina and CNC-Dre-h-er:in — every row. The shorter the input, the
more useless the result, and an initial is the shortest input anyone
would type.

A word now has to match at the start of a word: either the haystack
begins with it, or a space does. The haystack is first name, last name
and job title joined, with hyphens, slashes, colons and dots flattened
to spaces, so "dreher" still finds CNC-Dreher:in and "cnc" still finds
both the Dreher and the Fräser.

Checked against the live data before and after: "winkler h" now returns
Hannah Winkler alone, "h winkler" the same in either order, "winkler
kat" the two Katharinas, "dreher" the twelve CNC-Dreher.

The trigram index on the concatenated name no longer applies, which is
the price. At under nine hundred rows the scan is a few milliseconds; an
index on the same expression brings it back when that stops being true.

LIKE's own wildcards are escaped now — typing "100%" searched for
everything before.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-13 21:07:22 +02:00
272e8b1acf Put the fields back in one statement, not one at a time
Every deletion of a Vertragsänderung failed with "new row for relation
employees violates check constraint chk_weekly_hours". The revert wrote
one UPDATE per field, and chk_weekly_hours ties two of them together:
Vollzeit means exactly 38.5 hours, Teilzeit means something in between.
Setting the employment type back to Vollzeit while 37 hours still stood
produced precisely the state the constraint forbids. It hit nearly every
contract change, because the form changes those two together.

Collecting the assignments and writing them in a single UPDATE removes
the intermediate state entirely. The state being restored was valid once
— it is in the history because it was — so restoring it whole is safe.

A violation can still be real: if a later change touched one of a
coupled pair on its own, the old value no longer fits today's state.
That case is caught and reported as a sentence instead of surfacing a
database error in a toast.

My tests did not catch this, and could not have: the revert lives in SQL
and the suite has no way to run it. What did catch it was HR clicking
the button. The rehearsal script now covers the reported case, an
unrelated single-field revert, and the genuine conflict.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-13 21:00:47 +02:00
6297288c13 Let an entry be taken back, along with what it did
HR can now delete a history entry, but only where deleting one is an
honest thing to do — and deleting it also undoes it.

The rule they asked for is the interesting part: the last valid change
wins. Deleting an entry walks its fields one at a time. If a later entry
touched the same field, the current value stays — that later change is
the one in force. Otherwise the field goes back to what the deleted
entry recorded as its "before". So the middle of three entries can be
removed without an old value overwriting a newer one.

Four kinds of entry refuse to be deleted, each saying why in the place
the button would have been. Eintritt anchors the timeline. Transfers,
promotions, absences and exits moved positions and status — they have
proper operations for that, and guessing backwards is how you corrupt an
org chart. Anything not yet effective hangs off a planned change, and
that link is not trustworthy: there is no key between a history row and
its pending row, only a person and a date, and the data already has an
Eintritt and a Vertragsänderung sharing one. Matching on the date would
eventually cancel a change nobody meant. And entries from before the
history carried values have nothing to fall back to.

Confirmation is not "are you sure" — that question gets a reflex yes by
the third time. The dialog says what will be different afterwards: which
field goes back to which value, and which one stays because something
later claimed it.

employee_history keeps its append-only policies; delete_history_entry is
SECURITY DEFINER and checks the permission itself in its first line. The
audit log keeps the deletion with the values that were removed, and the
audit log genuinely cannot be edited.

The rule lives twice — in SQL and in lib/history.ts. The database is the
authority; the copy exists so the UI can hide a button that would fail
and print the reason instead. Rehearsed against real data in a
rolled-back transaction first: the later change held, the untouched
field reverted, all four refusals fired.

Also corrected in the data catalogue: I had written that
require_hr_admin was called by nothing. It guards all sixteen mutating
functions.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-13 20:56:48 +02:00
5f50cb97f3 Let the history say what an address was before
HR reported it from testing: change someone's address and their history
shows "Geänderte Felder: Adresse, Ort" — the new address is on the
Stammdaten tab, the old one is nowhere. It was recorded, but only in the
audit log, which is a different page sorted by time and actor rather
than by person. So you had to already know what you were looking for to
find out whether an address had ever changed, let alone what it used to
be.

The field-by-field diff was being built anyway and written to the audit
log. employee_history now carries the same list, and the person's
history renders it as an expandable Feld / Vorher / Nachher table — the
same table the audit log uses, lifted into a shared component so the two
views don't drift into reading differently. It expands with <details>,
so the values are in the page: findable with Ctrl+F, present when
printed, no script involved.

The duplication with audit_log is deliberate. A person's history should
be readable on its own, including after the log is eventually thinned by
a retention rule.

Rows written before today stay without values. They could only be
reconstructed from the audit log, and the link is not reliable — no key,
only a timestamp and a person. Honestly empty beats plausibly wrong.

The migration was generated from the live function definition rather
than retyped, and the diff is four lines: two column lists, two value
lists. It carries a self-check that raises if either insert failed to
pick up the new column, and it was rehearsed inside a rolled-back
transaction against real data first — the probe confirmed the old street
name lands in the history row.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-13 17:57:10 +02:00
00df973824 Stop the print preview measuring itself into a freeze
Opening the org chart PDF preview locked up the browser tab. The
measurement that fits each sheet to the page fed itself: the effect
listed onFaktor in its dependencies, and onFaktor was an arrow function
created fresh on every render, so the effect re-ran after every render.
It measured, reported the scale, and the report called setState with a
newly built object every time — new object, so React saw a change,
re-rendered, and the effect ran again. Measure, render, measure, until
React gave up with "Maximum update depth exceeded".

Two changes, and the mutation test says either one closes the loop on
its own: the callback now lives in a ref so the effect depends only on
the sheet identity, and the reducer returns the previous state unchanged
when the scale has not moved. Both are worth keeping — the ref stops the
effect from re-running, the guard stops pointless renders.

This shipped broken, and the reason it shipped is in the test file now.
Every element in jsdom is zero pixels, so the measurement bailed out on
its first line and the feedback never started; nine tests covering the
selection, the page count and the hierarchy all passed against a
component that froze on contact with a real browser. The new test gives
the elements a size, and fails with the exact error a user hits.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-13 17:44:20 +02:00
578ce696f0 Correct the policy count in the places that quote it
Six comments and doc lines put the number of RLS policies at 58. It is
21 — counted from pg_policy while building the data catalogue. The
figure appears in load-bearing prose ("all 58 policies call
is_hr_user()", "all 58 policies stay unchanged"), where being wrong by a
factor of three invites someone to go looking for the missing thirty-
seven.

The two occurrences inside supabase/migrations/ stay as they are. That
file already ran against the database; its comments record what was
believed at the time, and editing them would make the file differ from
what was applied for no gain.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-13 17:33:54 +02:00
917911457e Stop the seed handing out addresses that look like real ones
Every employee address in the database sat on test.manner.at, a domain
that reads like a company one. employees.email is the *private* address,
so an address shaped like a company mailbox invites being taken for one
— and eventually being written to. All 856 rows now sit on
privat.alpenwerk-test.at, rebuilt from first and last name, and the seed
generates the same domain so a reseed does not bring the old one back.

Umlauts are spelled out the way they are here (Höller becomes hoeller),
other accents are flattened, and where two people share a name the
personnel number is appended.

The first attempt got this wrong in a way worth recording. It wrote
ma<number>@ for all 856 rows instead of the intended name form, and the
check I had built only asked whether the results were unique and
well-formed — which they were. Two defects, both invisible to that
check: '\.+' inside a SQL literal was read as "any character, one or
more" and collapsed the whole local part to a single dot, and the
replacement string for the accent mapping had one character too many, so
the mapping was shifted. The fix uses '[.]+', a character class needing
no escape at all, so it no longer depends on how the connection treats
backslashes.

Untouched on purpose: app_users.email and profiles.email are the sign-in
accounts, and rewriting those would lock people out.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-13 16:00:29 +02:00
64eb155dda Write down what is actually in the database
The one document describing the schema, docs/data-model.md, predates two
rebuilds. It names divisions/departments/teams and a positions table that
no longer exist, describes Supabase auth with an anon key and a service
role that were removed, and puts the policy count at 58 when it is 21.
Anyone reading it to understand the data would have been misled on every
count.

docs/datenkatalog.md replaces it, and was not typed up from memory: the
columns, defaults, keys and check constraints were read out of
information_schema and pg_catalog on the running database. Fifteen
tables, 142 columns, ten enum types, 21 policies. Where a rule appears in
prose, the constraint it comes from is named next to it.

Some of it only became visible by asking the database rather than the
migrations. generate_company_email and the is_hr_admin pair are still
defined but nothing calls them any more. Position numbers look like a
six followed by seven digits because the generator builds them that way,
not because anything enforces it — the column requires only uniqueness.
monthly_salary_gross is dead weight kept in case old rows hold data.

Three claims I drafted were wrong and the database said so: the position
number format, the event trigger's name (ensure_rls, the function behind
it is rls_auto_enable), and which tables deviate from the plain
is_hr_user() policy.

The old document keeps a pointer at the top instead of being deleted —
it is linked from the security review, and a stale document that says so
is more useful than a dead link.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-13 07:46:49 +02:00
0b8f874fa5 Let the export select on everything the data model holds
The export offered four criteria — unit, location, status, employment
type — while the employee record carries around twenty selectable
attributes. Anything else had to be filtered by hand in Excel afterwards,
which is how a payroll hand-off stops matching the application it came
from.

All of them are now filters: contract type, blue/white collar,
collective agreement, paygrade, internal/external, gender, company car
and its drivetrain, works council, lateral leadership, C-level, type of
long-term absence, weekday worked, dependents on file, and open ranges
for entry, exit, birth date and weekly hours. The unit filter covers
every level rather than only divisions, so a single department can be
selected without going the long way round.

They live in one table in lib/report-criteria.ts, which the filter panel
builds itself from, the parser validates against, and the query turns
into conditions. A new criterion is one entry there and nothing else —
and it cannot end up working in the report while being silently ignored
by the export.

The two export links and the saved-report config now carry the query
string through as it stands instead of listing the parameters they know
about. That enumeration was the actual defect: adding a filter meant
remembering three separate places, and forgetting one produced an export
that quietly disagreed with the figure on screen.

Validation is not housekeeping here. These values reach SQL comparisons
and the download filename, i.e. a Content-Disposition header; what is not
in the list does not get through.

The company car dropdown leaves the employee list. It is one of twenty
equals under Berichte now, where the selection can also be exported —
which was the point of asking in the first place.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-12 12:40:47 +02:00
f14f1cb8df Keep the org chart inside the page it is printed on
Six divisions, each with its departments beside it, ran off the edge of
the sheet. The cause was structural, not cosmetic: every level spread
horizontally, so width multiplied with depth. Six divisions times three
departments is eighteen boxes across a landscape A4 — about two
millimetres each, if they had fitted at all, which they did not. They
overlapped and were clipped at the margin.

Now only one level spreads sideways. The divisions stand in a row and
everything below them hangs lengthwise off a vertical line, so width is
the number of divisions and nothing else. Depth costs height instead,
and on a landscape page height is what there is to spare.

What still overhangs is scaled down as a whole. The sheet in the preview
now carries the print area's exact dimensions rather than growing with
its contents, so the fit is measured against the real page: what you see
is what the printer gets. If a sheet has to shrink below 55% to fit, it
says so and points at A3, instead of quietly producing something nobody
can read.

With names switched on, each department gets its own sheet — a whole
division with every name was never going to be legible on one page — and
long name lists set in two columns so the box grows sideways rather than
pushing the scale down.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-12 12:40:31 +02:00
3151f32404 Print the org chart as an org chart, and ask first what to print
The chart on screen is an infinite canvas: you zoom in, drag around, and
look at one corner at a time. Paper has none of that. Printing the canvas
means scaling 850 people onto one sheet, which yields boxes two
millimetres wide — technically the whole company, practically nothing.

So the print view is rebuilt rather than shrunk, and it does two things
the canvas cannot.

It asks before it prints. Depth (bereiche, abteilungen, teams, or teams
with every name) and which divisions, each one selectable. Whoever needs
Produktion for a meeting gets two sheets instead of forty, and the page
count is on the button before anything reaches the printer.

And it draws the hierarchy as a hierarchy: boxes joined by connecting
lines, not a column of cards. Superior and subordinate are the entire
point of an org chart; a tidy list of the same units simply does not say
it. The lines come from borders on pseudo-elements, so the PDF keeps
them as vectors and they stay sharp when someone zooms in. Header
shading gets weaker with each level down, which survives the black-and-
white printer that most of these end up on.

Overview sheet first, then one sheet per selected division, each
carrying its own heading and headcount so page seven is still readable
on its own. A4 or A3, landscape.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 22:03:54 +02:00
c23df08648 Ask for the optional things separately, and stop claiming numbers are issued
A round of interface corrections from use, plus one schema change behind
them.

The private email address is now optional. It was NOT NULL — the wrong
default for a private detail: someone without one had to invent one, and
invented data in a personnel file is worse than missing data. Both fields
are relabelled to say whose they are, "Private E-Mail" and "Private
Telefonnummer", because the company address does not exist until the person
starts. Uniqueness stays; several NULLs coexist in a Postgres unique index,
which is exactly what is wanted.

The summary step still promised that "Personalnummer und
Firmen-E-Mail-Adresse werden automatisch vergeben". Neither is true any
more. Removed rather than reworded — the step lists what was entered, and a
banner claiming otherwise is worse than no banner.

Dependents move into the wizard as step three, optional. They can only be
attached after the hire, because add_employee_dependent needs an id that
does not exist while the form is open, so they are collected in the draft
and written afterwards. That puts them outside the transaction the person is
created in: if one fails the person still exists, so the message names who
is missing instead of failing silently, and the SV number is checked in the
step rather than after.

The emergency contact gets its own step, second to last, and its
relationship is a dropdown of the common ones rather than free text —
otherwise "Gattin", "Ehefrau" and "Frau" end up side by side and nothing can
be counted. "Sonstige" is there because a closed list would otherwise be
presumptuous.

On the master-data tab it now sits below the dependents rather than above:
both are people around the employee, and this is the one you reach for in a
hurry.

Returning from a long absence: the choice read "unverändert", which made you
open the file to find out what you were agreeing to. It now reads "Wie vor
Abwesenheit (38,5 h)" with the hours actually worked, and the alternative is
"Reduziert" — whose hours field starts empty on purpose. A number already
filled in gets confirmed rather than read off the agreement it comes from.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 21:47:04 +02:00
4eba557121 Show every field the edit dialog can change
The master-data tab summarised where the edit dialog itemises. Titles were
collapsed into one line, street, postcode and town were fused into a single
"Adresse", and first and last name appeared only in the page header — so
checking a value meant opening the change dialog to see it, which puts you
inside a form when you only wanted to look.

The tab now mirrors the dialog's "Person" section field for field and in the
same order, personnel number included.

Two deliberate departures from a literal mirror:

  - Standort sits at the end rather than between Adresse and Land. It is the
    workplace, not part of the person's address, and next to the postal
    fields it reads as though it were.
  - The emergency contact keeps the separate block it got earlier today,
    with its phone number as a tel: link. In an emergency someone reaches
    for it in a hurry; it should not be one cell among fourteen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 21:33:28 +02:00
9d754359e0 Enter the personnel number, tell the two kinds of company car apart, record who to call
Three requests from use, one of which changes the schema's mind about
something.

The personnel number is no longer issued. It was GENERATED ALWAYS AS
IDENTITY, which refuses a supplied value outright — but it has to match Loga
and Interflex, and a number this application invents is unknown there, so the
same person ends up with two. Identity dropped, entered everywhere instead:
in the wizard, in the import, and validated against a duplicate with a
message that names the number.

Worth stating plainly: the column had no unique constraint. The identity
prevented collisions as a side effect, and once the value comes from outside
that side effect is gone. The constraint is the point now, and it was
missing.

Company cars distinguish Verbrenner from Elektro, tied to has_dienstwagen by
a CHECK so "E-KFZ" cannot appear against someone without a car. The list
filters on it — with, without, only electric, only combustion — which is the
question the report was really about; it was answerable before only through
an export and manual work.

Emergency contact is name, phone and relationship. Relationship stays free
text: the examples given — Gattin/Gatte, Schwester/Bruder, Freund — are not
a list that closes without telling someone their arrangement does not count.
Name and phone are all-or-nothing, in the database and in both forms: a name
without a number helps nobody, a number without a name does not say who
answers.

Two mistakes of mine on the way, both caught by checks I had written into
the migrations rather than by me:

  - The first CHECK on the car type would have permitted exactly the case it
    was written against. `art in (…)` yields NULL rather than false when the
    column is null, and a CHECK counts NULL as satisfied. It needs an
    explicit `is not null` in front.
  - The constraint was added before the backfill, so it rejected every
    existing row with a car.

Existing cars are recorded as Verbrenner, which is an assumption — but a
visible one: "Elektro" appears nowhere nobody confirmed it.

hire_employee and change_employee_data both had to learn the new columns.
They name their columns one by one, and what is missing there is dropped in
silence — the interface would have collected the fields and thrown them
away, which is what happened to the email address this morning.

Verified against the live database, all rolled back: a hire without a number
is refused, a duplicate is refused naming it, a freely chosen one goes
through; E-KFZ plus contact arrive intact; a contact without a phone is
refused. A change records both, with before and after in the audit detail.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 21:27:00 +02:00
53d5d41784 Search a name by any of its words, in any order
Reported from use: typing "Winkler micha" suggests there is no Winkler at
all, when there are fourteen. The search compared the whole term against
each field separately, so a two-word entry matched nothing — neither the
first name nor the last name contains "Michael Winkler" as a string. Both
orders failed; the report noticed one of them.

The term is now split on whitespace and every word must match somewhere.
That is more than was asked — the request was to search surname first — but
reversing the expected order only mirrors the problem: you would still have
to remember which way round it goes. "Winkler kath" and "kath Winkler" both
find the two Katharina Winklers now, and "Winkler Produktmanager" finds the
two in that job.

Matching runs against the concatenated name rather than the separate
columns, because that is exactly what idx_employees_name_trgm indexes. The
old query could not use it.

A second defect in the same block: the personnel-number branch tested
/^d+$/ — a missing backslash, so it matched strings of the letter d and
never a number. Searching "3488" fell through to the name search and found
nothing. It now reaches Peter Bauer.

Verified against the live database, before and after, for both orders and
for a plain surname, which still returns all fourteen.

One thing the report's screenshot cannot show any more: there is no Michael
Winkler in the current data. The database was reseeded, and those names are
from the previous set — worth knowing before checking with that exact name.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 19:32:45 +02:00
f28fd2da60 Let a rehire choose the position, and make it work at all
Clicking "Wiedereinstellen" could never succeed. rehire_employee has always
demanded a position and refuses without one, but the panel offered only a
date and sent only a date — so every rehire ended on an error the dialog
gave no way to fix.

The panel now picks from the open positions, the same list and layout the
transfer panel uses, and warns before submitting when the date falls outside
the chosen position's validity. The old position is deliberately not a
silent default: it may since have been filled, ended, or gone.

Behind that sat a second fault, hidden by the first: the status assignment

    status = case when v_date <= current_date then 'Aktiv' else 'Geplant' end

is text, and the column is employment_status. Postgres refuses that outright,
so the function would have failed even with a position. It surfaced only once
the earlier check stopped firing — the same pattern as hire_employee this
morning, where three faults sat in a queue.

rehire_employee also placed people without checking anything. It now applies
the rule from 20260810100000: the date must lie in the position's validity,
and no assignment may still stand. A rehire could otherwise land on an
occupied position and be caught by the partial index, with a message that
explains nothing.

My first verification of the cast was wrong and passed a broken state:
plpgsql converts silently when assigning to a variable, so the probe proved
nothing. Redone as an UPDATE against a column, which is the case that fails.

Verified end to end against the live database, rolled back: Stefan Egger
returns as Aktiv on a free position, with the assignment and the
Wiedereintritt entry. Without a position, on an occupied one, and on one not
yet valid, it is refused — each with its own message.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 19:29:08 +02:00
27e0e8a8ce Ask for someone's organisation on a day they actually have one
An employee starting 01.09. showed "Keine Führungskraft (Geschäftsführung)"
although their team has one — Josef Bauer, on chief position 60000752. The
reporting line was requested as of today, and today that person holds no
assignment, so om_reporting_lines() returned no row at all.

The database function was right; the caller asked the wrong question.

What made it look like a data problem rather than a date problem: the header
did show the unit and the position, because pickPlacements() falls back to
the next best assignment when none is current. Two notions of where someone
sits — one forgiving, one strict — sitting next to each other on the same
page.

orgAsOf() pulls the date into the employment: the first day for someone not
yet started, the last for someone who has left, today otherwise. Exit dates
are exclusive throughout the model, so the last working day is the day
before.

Anyone already gone had the same defect for the same reason, which is why
the rule covers both ends rather than special-casing the case that was
reported.

Verified against the live database: as of today no row, as of 2026-09-01 the
manager is Josef Bauer. Six unit tests over the boundaries, checked by
mutation — remove the future-entry branch and one fails.

Open positions still resolve as of today: they belong to the organisation,
not to the person whose file is open.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 16:23:21 +02:00
92685f0ac0 Only staff a position while it exists
hire_employee and transfer_employee checked whether the position was free,
never whether it was there. Someone could be hired today onto a position
that starts in October, or onto one that lapsed in spring: the assignment
sat in the database while the position was absent from the org chart, and
the person hung off a structure that did not exist on their entry date.

That stopped being theoretical when the positions view began showing future
positions — they now appear in the same picker the hire wizard uses. This is
the rule that makes showing them safe.

The date of the assignment must fall in [valid_from, valid_to). valid_to is
exclusive throughout the model, as in lib/positions.ts.

Second correction in the same place: occupancy only looked at assignments
with an open end, so one ending later was invisible and the position could
be double-booked — the same gap the vacancy list had.

And a defect the verification exposed rather than the report: the work_days
default in hire_employee never applied. `array(select …)` over a missing key
yields an empty array, not null, so coalesce kept `{}` and the CHECK
constraint refused the row. Invisible through the wizard, which always sends
them and will not proceed without — but a default that defaults to nothing
is worse than none, because it reads as though the case was considered.

Verified against the live database, all rolled back: a hire onto a future
position is refused naming the date it begins, a transfer likewise, a hire
onto a currently valid one succeeds — and now also succeeds without
work_days, arriving with Mo–Fr.

The migrations match on a pattern rather than literal text: the function
bodies carry CRLF, and a literal search would have found nothing while the
migration reported success. Both refuse to proceed if the pattern matches
nothing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 16:10:18 +02:00
d8a1fdf43b Reinstate the Vercel build settings
Reverts 61ccce5, which reverted ecbda3f. The decision came back to Vercel,
so the two platform accommodations return: output: "standalone" is
conditional on VERCEL again, and /api/import goes back to 60 seconds, the
free tier's ceiling.

The Docker path is unaffected and stays documented — including the internal
network notes and deploy/Caddyfile written in between, which remain correct
for anyone taking that road. DEPLOYMENT.md conflicted at the top and now
carries both introductions instead of one replacing the other.

Verified with VERCEL=1: builds clean and emits no standalone directory.

Stated once and recorded here rather than repeated: Vercel's Hobby plan
excludes commercial use, and this is a company's HR system. Defensible while
the database holds nothing but the 852 invented people from the seed;
Pro at $20/month is the licensed path once real personnel data is in it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 08:32:47 +02:00
780f8fe2b7 Write down what an internal deployment actually needs
The target is a VM inside the company network, reachable only from there.
Two consequences decide whether this works at all, and both are easy to
discover too late — after the firewall rules are already written.

The server needs outbound access even though nothing comes in. Auth.js
exchanges the authorisation code for a token server-side and fetches the
issuer's configuration, so login.microsoftonline.com must be reachable from
the VM; the database likewise. That the person signs in through their own
browser is not enough, which is the assumption worth naming before someone
builds a closed network around it.

HTTPS is not optional either: Entra accepts http only for localhost. The
practical route without public reachability is a public DNS name pointing at
a private address and a certificate obtained through the DNS challenge —
allowed, common, and it yields a normally trusted certificate while the
server stays unreachable from outside. deploy/Caddyfile does that, and the
alternative (self-signed, trusted on every workstation) is written down with
its cost.

docker-compose now publishes port 3000 on 127.0.0.1 only. It was on every
interface, so the same service also stood there unencrypted, and one gap in
the firewall was enough. The proxy is the only way in.

AUTH_URL is documented for the same reason a comment sits in the Caddyfile:
behind a proxy the container does not see the name the browser used, and the
callback would point somewhere nobody can reach.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 08:26:14 +02:00
56662c0775 Describe what is actually deployed, now that the target is a Linux server
The revert restored three statements that stopped being true earlier today.

"Nicht containerisiert: Supabase (Datenbank + Auth)" — authentication is no
longer Supabase, it is Entra ID with an Auth.js session cookie, and the
database is any PostgreSQL 15 or later reached through DATABASE_URL. Supabase
is one option among several now, not the architecture.

The CI/CD note told the reader to pass --build-arg values for NEXT_PUBLIC_*.
Those variables no longer exist and the Dockerfile stopped taking build
arguments today. Following it would produce a puzzling failure; the point
now is the opposite one, that no build arguments are needed at all and the
same image runs everywhere.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 08:23:30 +02:00
61ccce5456 Revert "Make the build fit Vercel without breaking the container"
This reverts commit ecbda3f. The deployment goes to a Linux server instead,
so the two accommodations no longer earn their place: output: "standalone"
returns to unconditional, which is what the Dockerfile wants, and
/api/import goes back to 120 seconds — the free-tier ceiling that forced 60
does not apply outside a serverless platform, and a large import benefits
from the headroom.

The Vercel section in DEPLOYMENT.md goes with it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 08:21:58 +02:00
ecbda3f3a5 Make the build fit Vercel without breaking the container
Two settings were wrong for a platform build.

output: "standalone" tells Next.js to emit a self-contained server, which is
what the Dockerfile copies in — and what Vercel neither needs nor expects,
since it builds and packages the app itself. It is now conditional on the
VERCEL variable, which every build there sets, so each path gets what it
wants. Verified both ways: with VERCEL=1 no standalone directory appears,
without it one does.

/api/import declared maxDuration = 120. The free tier caps at 60 and refuses
anything higher, so the deployment would have failed on a value chosen for a
self-hosted server. Lowered, with the reason and the Pro ceiling written
next to it.

DEPLOYMENT.md now covers both paths, and says plainly that the repository
cannot be connected: git.elycon.solutions is self-hosted, and Vercel's git
integration only speaks GitHub, GitLab and Bitbucket. Deploying from the
workstation with the CLI works with any repository and is the shorter road;
mirroring to GitHub is written down as the alternative, with its cost — two
remotes to keep in step.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-06 15:17:24 +02:00
27cfd6431f Let a second person be activated at all
profiles.id referenced auth.users. Sign-in goes through Auth.js now and
creates nothing there, so a new colleague could sign in, receive an
app_users row, and then be impossible to authorise: the profiles row needed
to grant HR access could not be inserted. She would see "Kein HR-Zugriff"
with no way to change it.

All eight foreign keys in the public schema now point at app_users, walked
from the catalogue rather than written out — their names come from different
migrations and one transcribed wrongly means it silently stays behind. The
delete behaviour is preserved: profiles still cascades from the account,
audit and note fields do not, because an entry must not vanish when an
account is removed.

Every referenced value was already present in app_users, so nothing moved;
only the guarantee changed. A backfill from profiles runs first anyway, for
copies of this database where someone created something in between.

The check at the end does the thing that matters: it creates a second
account with a profile and removes it again. Counting constraints would have
passed while the actual case still failed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-06 12:15:27 +02:00
0d8af7cdf0 Refuse a save that changes nothing instead of reporting success
update_position returned quietly when no field differed, and the interface
answered "Planstelle geändert." — a confirmation for something that had not
happened. It now raises, and the message says so.

This is reachable without the user doing anything wrong: the chief checkbox
is dropped on the way out when the unit already has a chief position, so a
save consisting only of that tick arrives as an empty change set. The reply
was a green toast and an unchanged list, which sends someone looking in the
wrong place.

It also separates the two explanations for "I saved and nothing happened",
which is why it went in now: an empty change set is refused in red, so a
green confirmation with a stale card can only mean the page did not reload.

Verified against the live database: an unchanged payload is refused, a
changed one goes through.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-05 14:57:31 +02:00
a87c688c0a Show positions that do not exist yet, and let them be corrected
Two gaps in the positions view, both reported from use.

A position dated into the future was invisible. loadOpenPositions required
valid_from <= today, so a position decided now and effective at the quarter
boundary appeared nowhere until the day it began. The database already held
one — 60000824 "Neue Position", effective 01.09. — created through the
application and shown on no screen since.

Future positions now have their own section rather than joining the vacancy
list. They are a different statement: "nobody is here" and "this does not
exist yet" should not be counted together, and a position starting 01.10.
read as a vacancy nobody was filling.

Positions could only be created and deleted. Fixing a typo in the job title
meant deleting and recreating — with a new position number, which appears in
job postings, budgets and audit entries, and whose trail then breaks.
update_position keeps the number and records old and new values per field,
using the audit detail added earlier today.

Three things it refuses, as guards rather than remarks:

  - Moving an occupied position to another unit. That is a transfer, with
    history and reporting line, and belongs to the person — otherwise
    someone changes department silently.
  - Ending an occupied position, which would leave an assignment without
    one.
  - A second chief position in a unit, or an end before the start.

Verified against the live database, all rolled back: each guard fires with
its own message, the permitted edits go through, the audit entry carries the
changed fields. Open positions stay at 9 and the future one now appears in
its own section.

ESLint caught me priming the dialog's fields from an effect. Replaced by a
key on the component, so React rebuilds it per position and the fields
initialise from props — which also removes the flash of the previous
position's values on second open.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-05 12:26:12 +02:00
e44f71a60d Stop offering positions that are already spoken for, and let hiring work again
Two reports, four defects, all of them in the way of ordinary use.

A position with a signed starter is not vacant. loadOpenPositions asked "is
anyone on it today?", so three positions whose new holders begin in
September and October were listed as open, labelled "vacant for 2 days".
That same list feeds the hire wizard, so it invited filling a position a
second time — discovered at the partial unique index, after the second
interview. Vacancy now means no assignment that still stands, including one
that has not started. An assignment that ended still frees the position.

Hiring was broken three times over, each fault hidden behind the previous
one:

  1. hire_employee cast to ::weekday[], a type that no longer exists — it
     was replaced by text plus a CHECK constraint and the function was never
     updated. apply_due_pending_changes had the same problem with
     ::relationship_type, which would have broken the nightly run.
     PL/pgSQL resolves types in embedded statements at execution time, so
     both functions were created without complaint and failed only in use.
  2. Fourteen functions called auth.uid(). The application connects as a
     role with no rights on the auth schema, so every write — hire,
     transfer, promote, exit, notes, positions — failed with "permission
     denied for schema auth". They now use app_current_user_id(), which is
     where #23 was heading anyway. Its own fallback also caught only
     "function missing" and now catches the privilege error too, so a call
     without session context returns null instead of raising.
  3. The audit line built a name as `payload->>'a' || ' ' || payload->>'b'`.
     `||` binds tighter than `->>`, so Postgres reads
     `payload ->> ('a' || ' ' || payload) ->> 'b'`. The ACL failure above
     had aborted analysis before the parser ever reached it.

And the wizard collected an email, showed it in the summary, and dropped it:
the server action's signature had no such field. employees.email is NOT
NULL, so every hire that got past the three faults above would have failed
there. It is now passed through and required in step one, rather than
refused by the database at the end of step four.

Verified against the live database, each rolled back: a hire now creates the
employee, the assignment, the history entry and an audit line reading "Probe
Einstellung"; open positions drop from 13 to 10, and the three that
disappear are exactly the ones with a starter.

Migrations rewrite the affected functions in place rather than restating
them — retyping 165 lines of working PL/pgSQL to change two words is the
larger risk. Each one asserts the result afterwards.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-05 12:10:17 +02:00
1271cef879 Record what a change was, not only which field it touched
The audit log said "Adresse, wirksam ab 30.07.2026". That names the field
and hides the answer: what did it say before? For a personnel record that is
the question the log exists to answer.

Both values are in hand at the moment of the change — v_old holds the row as
it was, the payload holds what is being written. change_employee_data
already compared them to decide whether to mention the field at all, then
dropped them. It now keeps them in audit_log.changes as
[{feld, vorher, nachher}], and derives the old one-line text from the same
array so existing views are unaffected.

Clicking a row opens the detail. Fields with no previous value read "leer"
rather than showing an empty cell, because "was not set" is itself a
statement.

Two honest limits, both stated in the panel rather than left to look like a
bug:

  - Existing entries cannot be enriched. The values were never captured;
    there is nothing to recover.
  - Hire, exit and import record no individual fields, so they show none.

The rewritten function also drops auth.uid() for app_current_user_id(),
which works on either system — one of the last few call sites before #23.

Caught while writing this: my scripted edit of types.ts silently did nothing
and my own check reported success, because the pattern matched
pending_org_changes. Redone with the editor. That is the second time a
regex-driven edit has lied about its result in this project.

Not verified end to end: the migration needs privileges I no longer hold
after the database password was rotated. Until it is applied the audit page
will not load, since it selects a column that does not exist yet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-03 14:54:03 +02:00
3926f1bb80 Load a whole organisation from a file, or none of it
Second half of the mass import: the transactional loader, the /import page
and a template generated from the same schema the validation uses.

Everything happens in one transaction. A half-loaded organisation — areas
without departments, positions without people — is worse than none, because
it looks like data. The dry run is the same code path with a rollback at the
end, so the report is built against the real current state rather than a
copy, and nothing is cached between checking and committing: the file is
sent twice. That costs one upload and avoids server-side state that can
expire, fill up, or be confused between two people.

Personnel numbers are taken from the file, not reassigned. personnel_number
is GENERATED ALWAYS AS IDENTITY, so this needs OVERRIDING SYSTEM VALUE and a
hand-written insert — worth it, because the number is on payslips, in files
and on badges. An import that reissues it is not a migration. The identity
counter is advanced afterwards; without that the next hire draws a number
the import already used, and the unique index refuses it weeks later, far
from the cause.

Three defects the first real run against the database exposed, none of which
typecheck, lint or 231 tests could have found:

  - weekly_hours is bound to employment type by a CHECK constraint: full time
    is exactly 38.5. The import reached the insert and was rolled back. Now
    it is a finding with a row number.
  - Titles are restricted to a fixed list by another CHECK. Same treatment.
  - setval() needs UPDATE on the sequence, which `usage, select` does not
    grant. Migration 20260803120000 adds it; until it is applied, an import
    containing people will fail at the last step and take itself back.

I also had exit_date > entry_date where the database has >=. Someone who
never starts enters and leaves the same day; the stricter rule would have
rejected a real case.

Verified against the live database through the actual route and session: a
file with four deliberate faults produced exactly four findings, each with
sheet, row and column, and the rollback left nothing behind.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-03 14:40:33 +02:00
16b37244c8 Read an import file without guessing what it means
First half of the mass import: a file becomes named sheets with typed rows,
and every rule that could reject a row is stated in one place.

Nothing here touches a database. The parser turns bytes into sheets, the
schema says which columns exist, and validation reports findings — the
existing state is passed in as a parameter. That is what makes 36 tests
possible without a connection, and the rules are the part worth testing.

Three decisions where the easy choice would have been silent corruption:

  - A two-digit year is refused. "15.08.68" is 1968 as a birth date and 2068
    as a contract end, and any rule invented here creates people not yet
    born.
  - "31.02.2026" is refused. Date turns it into March 3rd without complaint.
  - An unrecognised value in a yes/no column is an error, not "no". Read the
    other way, a typo in "Betriebsrat" quietly removes someone's dismissal
    protection.

CSV is parsed rather than split. German Excel writes semicolons because the
comma is the decimal separator, so the delimiter is sniffed from the header;
a semicolon inside a quoted address would otherwise shift every following
column and import the row plausibly wrong. Quoted newlines, doubled quotes
and the byte-order mark Excel prepends are all handled — the last one makes
the first column read as "?Personalnummer", which is invisible in an editor.

Validation collects every finding instead of stopping at the first. With 800
rows that is the difference between correcting once and uploading eight
hundred times.

One rule earns its place from experience: a history event dated before the
entry it belongs to is refused here, with a row number, because the database
refuses it too — mid-insert, without one.

My own slip, caught by the type checker: `a ?? b ? c : d` does not mean what
it looks like; ?? binds tighter than the conditional.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-03 14:27:49 +02:00
73656461d1 Catch a seed event dated before the entry it belongs to
pruefeInvarianten() checked that no history event falls after an exit, but
not that none falls before an entry — and the database enforces exactly
that, in trg_history_not_before_entry.

That gap explains why the live database holds 852 people and no history at
all. employee_history is the last table the seed writes and insertInChunks
throws on the first rejected chunk, so everything before it was already
committed while every one of the ~950 events was lost. The result did not
look like an aborted run. It looked like an application that shows little
history.

The cause was the timezone bug in isoDate() that this seed already
documents: dates built from local parts but formatted through UTC land a day
early in Austria, which put every "Eintritt" one day before the entry date it
was derived from. That is fixed; the database was simply never rebuilt.

A dry run now reports 951 events and no violation, so the current code is
sound. The check stays because it turns this class of failure into a refusal
before the wipe instead of an abort halfway through it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-03 13:48:01 +02:00
99e50fbbf9 Stop hoarding connections the provider will not give twice
The app died with "max clients reached in session mode - pool_size: 15".
Two causes, both real, neither visible without a live database.

The connection string pointed at the pooler's session mode, which pins one
backend per client and caps at 15 on Supabase. Every query here already runs
inside a transaction and the session context is set transaction-locally, so
transaction mode is not a workaround but the mode this design was written
for. Verified: 20 concurrent transactions, all 852 rows, 0.4s — and still
nothing without a session context.

The second cause was the dev server. Next.js re-evaluates changed modules,
so a module-local `let` was empty afterwards while the previous pool stayed
alive holding its connections. An afternoon of editing exhausted the quota.
The pool now hangs off globalThis, which is inert in production where
nothing reloads.

Documented in .env.example and DEPLOYMENT.md, because a deployment that
picks port 5432 fails this way under load and not before.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-03 10:28:36 +02:00
4d8e3f7154 Restore the shapes the application was written against
The app runs against a real database for the first time since the port, and
two things were broken. Both were invisible to typecheck, lint, 192 tests
and the build.

Sign-in looped. Auth.js created the session and app_upsert_user() adopted
the existing profiles id correctly — the row was in app_users, right id and
all — but the proxy builds its own Auth.js instance from lib/auth/config.ts
alone, and the session callback that copies token.uid onto session.user.id
lived in auth.ts. So the proxy saw a session without an id, treated every
signed-in user as signed out, and sent them back to /login. Click, flash,
login page: from the outside it looked like the button did nothing.

The callback moves to the config both instances share. auth.ts now spreads
the base callbacks instead of replacing them, which is the mistake that
would reintroduce this.

The proxy test did not catch it because its fixture hands the handler a
session that already has user.id — it tested the routing, not the shape
Auth.js actually produces.

Then the dashboard crashed on a.date.localeCompare. PostgREST returned JSON:
a `date` arrived as "2026-08-03", a `numeric` as a number, and that is what
lib/supabase/types.ts declares and what every sort, every date comparison
and every status derivation assumes. The pg driver does the opposite — Date
object and string respectively. The declarations stayed true to what the
code believes; only the runtime value changed, which is why nothing flagged
it.

The driver is configured back to the declared shapes in lib/db/pool.ts,
rather than rewriting 49 call sites. That also removes a timezone hazard:
`date` is a calendar day, and as a Date object it acquires midnight in the
server's zone — a birth date would shift by a day in Austria, always. The
same class of bug as in the seed.

int8 stays a string on purpose: it only comes from count() and is read
through Number() everywhere; parsed as a number it would quietly lose
precision past 2^53.

A missing sign-in error now reaches the server log. Auth.js was failing
silently — a 302 back to /login and nothing to read. That was its own
defect, and it is the reason the first diagnosis took as long as it did.

Verified against the live database: all six pages render, 797 active of
852 records, 744.4 FTE, and a detail page shows birth date 15.08.1968
against SV number 7960 150868 — the digits agree, so no day has shifted.
Both new tests were checked by mutation: remove the fix and they fail.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-03 10:11:34 +02:00
b9efe81bec Keep database snapshots out of the repository
Before applying the five pending migrations I took a full snapshot of the
live database — every table plus the source of all 61 functions. It sits in
.backups/ and holds 852 personnel records, so it must never be committed.

The ignore rule comes first, on its own, rather than riding along with the
next change: a snapshot that is already staged when someone remembers to
add the rule is a snapshot that has been in a commit.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-03 09:57:25 +02:00
2ba9b37aa7 Hand the front door to Entra, and keep the keys out of the build
Auth.js replaces GoTrue. The sign-in still goes to the same Entra tenant,
but nothing sits between the app and the identity provider any more — the
code exchange, state, nonce and the session cookie are ours.

lib/auth/session.ts stays the only place that knows where a user id comes
from, which is why this was one file and not fifty. What it returns is now
app_users.id. app_upsert_user() maps the Entra `oid` onto it, and for an
address that already has a profiles row it adopts that id instead of
minting a new one — otherwise everyone would have been signed in and cut
off from their own notes, drafts and audit trail at the same time.

That upsert is the one write that cannot have a session context yet: the
id is what it produces. It runs as a SECURITY DEFINER function that may
touch app_users and nothing else, which is a far smaller lever than the
service key that used to answer this class of problem.

The proxy no longer checks HR rights. It has no database connection, and
putting role/is_active in the token would have frozen the claim until the
next sign-in. The check moved to where it can read the current truth: the
app layout on every render, requireHrUser() for the export routes, and
underneath both, RLS.

Two things only came out by running it:

  - `export const proxy = auth(…)` is not a function declaration, so
    Next.js never found it and every request 404'd. `next build` reported
    success and listed the proxy. In the function config form auth() also
    returns the handler as a promise, so it needs an await. The proxy test
    now mocks it as a promise for that reason — a friendlier mock would
    let the same bug back in.

  - A missing AUTH_MICROSOFT_ENTRA_ID_ISSUER silently falls back to
    /common/, and the redirect really did go there. That would let any
    Microsoft account sign in, including a private one, and it would never
    look broken. It now refuses to start in production.

Neither build nor image needs credentials any more: the pool is created on
first use, the auth config is evaluated per request, and there are no
NEXT_PUBLIC_* values left to bake in. One image now runs in every
environment.

Verified: typecheck, lint, 187 tests, build, and by hand in the browser —
/employees redirects to /login, and the sign-in button reaches the Entra
page with PKCE and the callback URL that goes into the app registration.
Not verified against a real database; there is still no DATABASE_URL.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-31 14:57:32 +02:00
b3a0af2b8f Talk to PostgreSQL directly, and let the pooled connection forget
Zweiter Schritt weg von Supabase. Sämtliche 49 Lesezugriffe und alle
Mutationen laufen jetzt über lib/db statt über die REST-Schicht: Kysely auf
einem pg-Pool, jede Abfrage in einer Transaktion, in der zuerst
app.user_id gesetzt wird. Die Anmeldung hängt noch an GoTrue — sie liefert
die Kennung, die in withUser() geht. Damit war der Umbau in zwei Hälften
teilbar und die Anwendung durchgehend lauffähig.

Was dabei ersatzlos verschwindet:

  - fetchAllRows. Es gab die Funktion nur, weil PostgREST jede Antwort bei
    1000 Zeilen still abschneidet und ein Bericht dann leise falsch war.
    Am direkten Zugang ist eine Abfrage eine Abfrage.
  - sanitizeIlikeTerm samt Test. Sie entschärfte Zeichen, die in der
    Filtersyntax strukturelle Bedeutung hatten; jetzt wird der Suchbegriff
    als Parameter gebunden und ein Komma ist ein Komma. Die Lücke ist nicht
    abgesichert, sondern weg.
  - lib/supabase/admin.ts. Der Dienstschlüssel, der RLS aushebelte, hatte
    genau einen Aufrufer — den nächtlichen Lauf. Der benutzt jetzt dieselbe
    Rolle ohne BYPASSRLS und ruft eine SECURITY-DEFINER-Funktion auf, die
    selbst prüft, was sie tut. Es gibt keinen privilegierten Zugang mehr.

Nebenbei besser geworden, weil der direkte Zugang es erlaubt:

  - Eine Seite ist eine Transaktion. Das Layout etwa liest Profil,
    Planstellen, Standorte, Entwürfe und Notizen auf einem einheitlichen
    Lesestand statt in fünf unabhängigen Anfragen.
  - Der Bereichsfilter der Mitarbeiterliste ist ein EXISTS statt einer
    eingebetteten Ressource mit !inner — eine Person mit mehreren
    Zuordnungen über die Zeit erschien dort mehrfach.
  - Seitenweise Listen sortieren zusätzlich nach id. Bei gleichem Nachnamen
    oder gleichem Zeitstempel war die Reihenfolge vorher unbestimmt, und
    dieselbe Zeile konnte auf zwei Seiten erscheinen oder auf keiner.
  - Angehörige werden in der Datenbank gezählt statt alle Zeilen zu holen.
  - Namen an Ereigniszeilen kommen aus einem Join statt aus einem
    Nachschlag, der ausserhalb der Transaktion lag.

Der Statusfilter ist mitgezogen: dieselbe Regel wie deriveStatusAsOf,
Klausel für Klausel, jetzt als Kysely-Ausdruck. Der Integrationstest, der
beide über den gesamten Bestand vergleicht, läuft weiter — mit eigener
Verbindung, denn geprüft wird die Bedingung, nicht die Berechtigung.

Zwei Fehler auf dem Weg, beide vom Typprüfer gefangen: apply_due_pending_
changes() nimmt kein Argument, wurde von callFunction aber mit jsonb
aufgerufen — Postgres hätte keine passende Signatur gefunden. Und der
Sicherheitstest lädt jetzt Module mit `import "server-only"`, was ausserhalb
der Server-Übersetzung wirft.

Typecheck, Lint, Build und 180 Tests sind grün. Ungeprüft bleibt der Lauf
gegen eine echte Datenbank — dafür fehlt eine DATABASE_URL.
2026-07-31 08:45:26 +02:00
a66263a96e Put the session context under the app's own control
Erster Schritt weg von Supabase hin zu "läuft auf jedem PostgreSQL".

Gemessen sitzt die Kopplung nicht dort, wo der Begriff "Supabase-Projekt"
sie vermuten lässt: das Schema ist reines PostgreSQL, und von 58 RLS-Policies
rufen nur fünf auth.uid() direkt auf. Die übrigen 53 gehen über is_hr_user().
Diese eine Funktion ist die Brücke — wird sie umgelegt, folgt der Rest.

Die Migration legt sie um. app_current_user_id() liest jetzt zuerst
current_setting('app.user_id') und fällt nur ersatzweise auf auth.uid()
zurück. Deshalb plpgsql statt language sql: eine SQL-Funktion wird beim
Anlegen geparst, und auth.uid() gibt es auf einem gewöhnlichen PostgreSQL
nicht — die Migration liesse sich dort gar nicht erst anwenden. Der
Ausnahmeblock fängt das ab, und damit läuft dieselbe Migration auf beiden
Systemen. Der Rückfall verschwindet mit der Abschlussmigration.

Dazu app_users als Nachfolger von auth.users, external_id ist die oid des
Anbieters statt der E-Mail: eine Namensänderung darf kein zweites Konto
erzeugen.

Die neue Zugriffsschicht ist Kysely auf einem pg-Pool. Was daran zählt, ist
nicht der Query-Builder, sondern was er verhindert:

  - Die Kysely-Instanz wird nicht exportiert. Wer abfragen will, geht durch
    withUser() — und das öffnet immer eine Transaktion.
  - set_config(..., true) ist transaktionslokal. Ohne das dritte Argument
    bliebe die Kennung an der gepoolten Verbindung kleben und die nächste
    Anfrage liefe im Namen der vorherigen Person. In einer Personaldatenbank.
  - Eine ESLint-Regel verbietet den Import von pg und von lib/db/pool
    ausserhalb von lib/db. Nachgewiesen: eine Testdatei mit beiden Importen
    erzeugt zwei Fehler.
  - Einen privilegierten Zugang gibt es nicht mehr. asSystem() benutzt
    dieselbe Rolle ohne BYPASSRLS; was ohne angemeldete Person laufen darf,
    muss als SECURITY-DEFINER-Funktion in der Datenbank stehen.

tests/integration/session-context.test.ts läuft gegen einen Pool mit genau
einer Verbindung — sonst träfe er die Lücke mal und mal nicht. Er prüft, dass
nach Commit *und* nach Rollback nichts an der Verbindung zurückbleibt, und
belegt in einer Gegenprobe, dass eine Einstellung ohne Transaktion tatsächlich
hängen bleibt. Ein Sicherheitstest, der sich mangels DATABASE_URL selbst
überspringt, wäre schlimmer als keiner: in der CI schlägt schon das Fehlen
des Verbindungsstrings fehl.

Beim Schreiben der Migration stellte sich heraus, dass die Policies
hire_drafts_owner und saved_reports_owner heissen, nicht _own. Mit dem
geratenen Namen hätte drop policy nichts getroffen und create policy wäre mit
"already exists" abgebrochen.

Typecheck, Lint und 182 Tests sind grün. Die Anwendung läuft unverändert
weiter — sie benutzt die neue Schicht noch nicht.
2026-07-30 19:01:39 +02:00
730521ee79 Keep the environment's identifiers out of the repository
Projekt-Ref, Entra-Client- und Tenant-ID standen im Klartext in der
SSO-Anleitung. Geheimnisse sind das nicht — ohne Schlüssel gibt eine
Projekt-URL nichts her, und RLS greift unabhängig davon. Sie zeigen aber auf
die laufende Umgebung, und dieses Repository wandert weiter als sie: es geht
gleich auf einen eigenen Git-Server und später an den Kunden.

Jetzt Platzhalter; die Werte gehören in die Übergabedokumentation. In der
Historie stehen sie weiterhin — das sauber zu entfernen hiesse, die Historie
neu zu schreiben, und das passiert nicht nebenbei.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-30 18:39:20 +02:00
acbb03c4f5 Record the supported Node range in the lockfile
package.json declares engines: node >=22 <25; npm writes that into the
lockfile on the next install. Committing it keeps a fresh clone from
producing a diff on the first npm ci.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-30 18:37:44 +02:00
ee1a38492c Pin search_path, and close a write path that needed no login
Der Security Advisor meldete 34 Warnungen; nach dem Festnageln des
search_path sind es zehn. Von diesen zehn ist eine einzige ein echter Befund
— aber die hätte man in den 34 nicht gesehen.

search_path (34 Warnungen)

Alle betroffenen Funktionen sind SECURITY INVOKER, laufen also mit den
Rechten der aufrufenden Person; ein manipulierter Pfad bringt dort nichts zu
holen. Die vier DEFINER-Funktionen setzen ihn längst. Festgenagelt wird es
trotzdem, für den Tag, an dem jemand eine davon auf SECURITY DEFINER
umstellt, weil eine Mutation an RLS vorbei schreiben muss — dann wäre es eine
Rechteausweitung, und an den search_path denkt in dem Moment niemand.

Als Schleife statt als Liste von 34 Signaturen: die würde beim nächsten
Umbau veralten. Sie lässt Erweiterungen in Ruhe (pg_trgm legt show_trgm und
show_limit ebenfalls in public ab) und prüft am Ende selbst nach. pg_temp
steht ausdrücklich am Pfadende — ohne die Angabe durchsucht Postgres das
temporäre Schema zuerst, und dort darf jede Sitzung anlegen, was sie will.

Ausführungsrechte (8 Warnungen)

Hier trennt sich der Befund vom Rauschen, und zwar durch Messen mit dem
anon-Schlüssel gegen die laufende Datenbank:

  anon.rpc(is_hr_user)                -> false
  anon.rpc(current_hr_user_id)        -> null
  anon.rpc(apply_due_pending_changes) -> 0

Die ersten beiden bleiben offen, und das ist keine Nachlässigkeit: sie werden
aus den RLS-Policies heraus aufgerufen, und ein Policy-Ausdruck wird mit den
Rechten der abfragenden Rolle ausgewertet. Ohne EXECUTE scheitert jede
Abfrage auf jeder Tabelle. Preisgegeben wird nichts — beide nehmen keine
Argumente und beantworten nur eine Frage über die aufrufende Person selbst.

Der dritte ist der Befund. apply_due_pending_changes() wendet vorgemerkte
Versetzungen, Beförderungen und Abwesenheiten an, ist SECURITY DEFINER,
umgeht damit RLS — und war ohne Anmeldung aufrufbar. Der anon-Schlüssel steht
im ausgelieferten Browser-Bündel. Der Schaden wäre begrenzt, weil nur ohnehin
fällige Änderungen angewandt werden, aber es ist ein Schreibpfad für Fremde
und macht das Geheimnis der Cron-Route wirkungslos. Entzogen für anon und
authenticated; die Route benutzt die service_role und läuft weiter.

rls_auto_enable() stammt nicht aus diesen Migrationen und wird nirgends
aufgerufen. Der Entzug ist risikolos und beantwortet die Frage, was sie tut,
notfalls mit einer klaren Fehlermeldung.

Zwei Warnungen bleiben bewusst stehen

pg_trgm in public trägt die Operatorklasse gin_trgm_ops, auf der zwei
GIN-Indizes auf employees liegen. Ein Schemawechsel müsste Indizes und jeden
search_path mitziehen — Risiko für eine Konvention, keine Rechteausweitung.

„Leaked Password Protection" ist gegenstandslos: die Passwort-Anmeldung ist
abgeschaltet, eine Anmeldung gegen die API antwortet mit
email_provider_disabled. Es gibt kein Passwort, das kompromittiert sein
könnte.
2026-07-28 11:54:02 +02:00
2cce101c4b Sign in with Entra ID, and give the login screen something to look at
Die Anmeldung läuft über das Firmenkonto. Supabase Auth bleibt dabei die
Sitzungsverwaltung — Entra ist der Anbieter, nicht der Ersatz. Genau deshalb
ist der Eingriff klein: auth.uid() liefert weiterhin eine UUID, profiles.id
trägt weiterhin role und is_active, und damit bleiben is_hr_user() und alle
58 RLS-Policies unverändert gültig. Die Sicherheitsgrenze wandert nicht in
den Anwendungscode.

Der Passwort-Pfad ist weg, nicht deaktiviert. Ein zweiter Anmeldeweg neben dem
Firmenkonto hebelt jede Vorgabe des Mandanten aus — Mehrfaktor, bedingten
Zugriff, Sperrung beim Austritt.

Dazu die Rückweg-Route /auth/callback, die den PKCE-Code gegen eine Sitzung
tauscht, und eine Ausnahme im Proxy: ohne sie leitet der Gate den Code nach
/login um, weil es die Sitzung ja erst danach gibt, und die Anmeldung kommt
nie zustande. Ob jemand HR-Zugriff hat, entscheidet weiterhin nicht die Route,
sondern profiles.role/is_active und darunter die Policies.

Zwei Werkzeuge für die Umstellung:

  - relink-profile.ts hängt eine bestehende profiles-Zeile auf die
    Entra-Identität um. Ein Passwort-Konto und das Entra-Konto derselben
    Person sind für Supabase zwei Benutzer mit verschiedenen IDs; ohne das
    zeigt die profiles-Zeile nach der ersten SSO-Anmeldung ins Leere und man
    sperrt sich aus. Die Fremdschlüssel auf auth.users wandern mit, sonst
    stünde in der Historie eine Kennung ohne Konto dahinter.
  - entra-claims.ts zeigt, was der Anbieter tatsächlich mitgeschickt hat.
    Die geplante Freischaltung über eine Entra-Gruppe hängt daran, wie der
    Anspruch heisst und aussieht, und das unterscheidet sich je nach
    Tokenkonfiguration des Mandanten. Der Trigger wird erst danach gebaut,
    sonst wäre er geraten.

Beim Auswerten der Gruppe später gilt: die Quelle ist auth.identities.
identity_data, nie raw_user_meta_data. Letzteres beschreibt die angemeldete
Person über updateUser() selbst — läse die Freischaltung von dort, könnte sich
jede:r Angemeldete HR-Rechte eintragen. Steht so in docs/entra-sso.md.

Die Anmeldeseite war eine Box im leeren Rosa. Jetzt zweispaltig: links eine
Markenfläche, rechts die Anmeldung; unter 1024px fällt die Fläche weg und die
Wortmarke rückt über die Karte. Die Microsoft-Schaltfläche ist bewusst nicht
mehr in der Hausfarbe — magenta las sich als Aktion *innerhalb* dieser
Anwendung, während sie auf eine fremde Anmeldeseite springt. Weiss mit
grauem Rand ist Microsofts eigene Vorgabe und das Muster, das man
wiedererkennt. Dazu ein Wartezustand für den Sprung und eine Fehlermeldung,
die erklärt, was zu tun ist, statt nur "Kein HR-Zugriff" zu behaupten.

Nachgemessen im laufenden Server statt geschätzt: 656/624 auf 1280px,
Markenfläche in brand-700, Schaltfläche 45px hoch, kein Querlauf auf 375px.
Typecheck, Lint, Build und 182 Tests sind grün.
2026-07-27 20:34:00 +02:00
27669e0359 Put the whole application on the OM model, and delete what it replaced
Die Datenbank stand seit dem Cut-over auf org_units/om_positions/
position_assignments, die Anwendung fragte weiter nach employees.division_id,
team_id und manager_id — Spalten, die es nicht mehr gab. Die Oberfläche war
deshalb leer, obwohl die Daten vollständig da waren. Das ist jetzt behoben,
und zwar nicht durch Nachbau der alten Begriffe, sondern indem sie verschwinden.

Neu ist eine dünne Schicht, die die Verkettung Person → Besetzung →
Planstelle → Einheit einmal auflöst (lib/placement.ts) und der Baum als reine
Funktionen darauf (lib/org.ts): Vorfahrenkette, Teilbaum, Brotkrume. Alles
Weitere hängt daran.

Was sich dadurch von selbst erledigt hat:

  - Das Organigramm musste drei Quellen versöhnen, weil keine den ganzen
    Zeitstrahl abdeckte. position_assignments ist zeitabhängig, also
    beantwortet eine Abfrage "wer besetzte am Stichtag welche Planstelle" —
    für Vergangenheit und Zukunft gleichermassen. Wer keine Planstelle hatte,
    war nicht da; eine zweite Zugehörigkeitsregel braucht es nicht mehr.
  - Die Struktursicht war auf genau vier Ebenen verdrahtet und rendert jetzt
    rekursiv über parent_id. Liste und Grafik entstehen aus *einem* Baum;
    vorher lag dieselbe Hierarchie zweimal vor und konnte auseinanderlaufen.
  - Eine offene Stelle ist keine eigene Tabelle mehr, sondern eine Planstelle
    ohne laufende Besetzung — das Komplement kann nicht aus dem Tritt geraten.
  - Eine Versetzung ist der Wechsel auf eine Zielplanstelle statt Zielteam
    plus frei getipptem Titel. Sie kann damit nicht mehr dort landen, wo es
    keine Stelle gibt, und die Tätigkeit kommt aus dem Job-Katalog.
  - Beim Anlegen einer Planstelle entfällt die Suche nach der vorgesetzten
    Person: sie ergibt sich aus der Einheit, die Frage kann nicht mehr falsch
    beantwortet werden.

Zwei Auswertungen werden dabei richtiger, nicht nur anders. Ein
Stichtagsbericht gruppierte bisher nach der *heutigen* Zuordnung, weil es
keine Historie gab; er löst sie jetzt zum Stichtag auf. Und ein Ereignis
trägt die Einheit, in der die Person am Tag des Ereignisses sass — vorher
stand ein Austritt von vor zwei Jahren unter einem Team, in das sie nie
versetzt worden war. Der Bereichsfilter greift überall auf den ganzen
Teilbaum; auf den Bereich allein angewandt lieferte er nur die
Bereichsleitung.

Gelöscht: die Reorganisations-Werkbank samt Szenarien und Zügen (sie
verschob Teams und Abteilungen zwischen Bereichen — Objekte, die es nicht
mehr gibt; im OM-Modell ist das ein Umhängen von parent_id), die
Mitarbeiter- und Vorgesetztensuche, die nur sie und die Ausschreibung
brauchten, und aus lib/supabase/types.ts die Tabellen divisions,
departments, teams, positions und employee_assignments.

Die beiliegende Migration räumt die Datenbank entsprechend auf. Sie entfernt
auch Funktionen, die der Cut-over verfehlt hat: create_position,
delete_position und undo_reorg existierten zusätzlich in einer
jsonb-Variante und tauchen deshalb weiter in der PostgREST-Schnittstelle auf,
obwohl ihre Tabellen weg sind — ein Aufruf wäre erst zur Laufzeit
gescheitert. An ihre Stelle treten create_position und delete_position im
OM-Sinn; letzteres schliesst eine früher besetzte Planstelle, statt sie zu
löschen, sonst verschwände mit ihr die Besetzungshistorie.

Typecheck, Lint, Build und 182 Tests sind grün. Die Integrationstests sind
mitgezogen, aber weiterhin ungelaufen — dafür braucht es eine laufende
lokale Datenbank.
2026-07-27 20:02:26 +02:00
4929252f45 Seed the OM model from scratch, and stop writing dates through UTC
Alle Daten gelöscht und neu aufgebaut: 60 Organisationseinheiten, 133 Jobs,
823 Planstellen, 852 Personen, 852 Besetzungen. Die Anmeldekonten bleiben
stehen — ein Seed, der sich selbst aus der Anwendung aussperrt, ist keiner.

Der Baum kommt aus buildOrg(); der Seed entscheidet nur noch, wer welche
Planstelle besetzt. Damit fällt die halbe Datei weg: keine division_id,
team_id, manager_id, org_level, is_lead mehr auf der Person.

Zwei Dinge, die das Altmodell nicht abbilden konnte, stehen jetzt bewusst in
den Daten:

  - Vakanz ist eine Planstelle ohne laufende Besetzung, keine eigene Tabelle.
    14 Planstellen sind heute unbesetzt, drei davon mit einem Eintritt in der
    Zukunft — die Besetzung beginnt später, die Planstelle existiert schon.
  - Ausgetretene sind Vorgänger:innen auf heute besetzten Planstellen, nicht
    Karteileichen an einem Team. Vorher liessen sie deren Planstellen als
    vakant erscheinen.

Drei Teamleitungen sind unbesetzt und zwei langzeitabwesend, damit die
Hochroll-Regel überhaupt Daten hat: 76 der 809 Berichtslinien weichen von der
formalen ab. Genau eine Person hat keine Vorgesetzte, die Geschäftsführung.

Beim ersten scharfen Lauf hat der SVNR-Trigger mitten im Einfügen abgebrochen,
mit bereits geleerter Datenbank. Ursache war nicht die Prüfziffer, sondern
isoDate(): es ging über toISOString(), während makeSvNummer die lokalen
Datumsteile liest. In Österreich verschiebt das jedes Datum um einen Tag — das
gespeicherte Geburtsdatum passte nicht mehr zu dem in der SV-Nummer codierten.
isoDate rechnet jetzt lokal, wie der Rest des Seeds auch.

Damit so etwas nicht wieder erst die Datenbank leerräumt: pruefeInvarianten()
läuft *vor* dem Löschen und prüft, was sonst erst die Unique-Indizes und
Trigger abfangen — doppelte Besetzungen, überlappende Historie, Ereignisse
nach dem Austritt, und jede SV-Nummer gegen ihr Geburtsdatum. Mit --dry-run
schreibt der Seed gar nichts und meldet nur, was entstehen würde.
2026-07-27 15:06:10 +02:00
c2366e3408 Make the cut-over script safe to paste, and record the Azure design
The mapping table was declared ON COMMIT DROP. In the Supabase SQL editor
the transaction boundaries are not ours to assume, and a mapping table that
vanished between the two inserts would leave positions without assignments
and be miserable to diagnose. It is now dropped explicitly once both inserts
have run.

docs/azure-migration.md is the design for the Azure move, for review before
any code changes.

Its main finding corrects what I said when I laid out the options: I claimed
that dropping Supabase would push the security boundary into application
code. It does not. auth.uid() appears 70 times, but only one of them matters
— inside is_hr_user(), which all 58 policies call. Swapping the source of
the user id there leaves every policy valid, so the database stays the
boundary.

The risk moves elsewhere, and the design says so plainly: the user id
arrives via set_config(..., true), which is transaction-local. Outside a
transaction it sticks to the pooled connection, and the next request on that
connection runs as the previous user. So the plan makes that structurally
impossible — a single access function that owns the transaction, a lint rule
against importing the pool anywhere else, a database role without BYPASSRLS
so a missing context returns nothing rather than everything, and a test that
sends two requests over one pooled connection to prove the second cannot see
the first.
2026-07-27 14:39:57 +02:00
cce5c6b0ce Cut-over SQL: migrate the existing org data into the OM model, drop the old
One script for the Supabase SQL editor. It transforms rather than wipes:
divisions/departments/teams become org_units, every employee gets a position
and an assignment, so the org chart is populated the moment it finishes.

The Abteilungsleitung positions are created *vacant*. Nobody holds them, and
inventing holders would be worse than a visible gap — the upward rule skips
an unfilled chief, so the reporting line stays unbroken either way.

Mutations are rewritten onto the model. The reporting line is derived now,
which removes manager bookkeeping from all of them: terminate_employee no
longer reassigns direct reports at all, because they roll up on their own.
Transfer becomes what it is in OM — end one assignment, begin another.

apply_reorg, undo_reorg, create_position, delete_position and
staff_position_internally are dropped rather than rewritten: they need the
UI to move to org units first, so rewriting them now would be guesswork.
Those screens are out until the port.

Written by inspection, not by running it — Docker is not up and the project
is not linked, so this is unverified SQL. Re-reading the first draft caught
five defects that would each have aborted it: a window function inside a
JOIN condition, a jobs insert placed after the positions referencing it,
row_number() computed twice for a mapping that has to agree, a DROP VIEW
naming a view that does not exist while the real one (employees_directory)
depends on the columns being dropped, and exit_date = entry_date violating
the assignment range check. There may be more.
2026-07-27 12:58:16 +02:00
35f17858d8 Build the org tree in the OM model as a tested pure function
Constructing the tree is where parent links, chief positions and number
ranges get wired up wrongly without anyone noticing — a team under the wrong
Bereich looks perfectly plausible in the org chart. So the construction is a
pure function taking an id generator, and the checks that matter are asserted
rather than eyeballed: exactly one root, every unit's parent of the expected
type, every unit reaching the root, one chief position per unit, unique
numbers in the right ranges, and every position pointing at a real unit and
a real job.

Also introduces the job catalogue this model needs. job_title was free text
per person, so "Schlosser:in" and "Schlosser" could coexist and no breakdown
by occupation was possible; jobs are now deduplicated by title and shared
across positions.

Every Abteilung gets a chief position, which is the level the old three-table
model had no room for.

Correction to the previous commit message: it claimed the cut-over could
follow later while the old tables kept working. It cannot. The legacy
resolve_manager_for() finds a Bereichsleitung by "division_id = X and
team_id is null and org_level = 1", and an Abteilungsleitung satisfies the
same predicate — its LIMIT 1 would then pick one of the two arbitrarily. The
two models cannot both be correct once the new level is populated, so the
remaining work is a single cut across the 11 RPCs that read the legacy
columns, not a gradual migration.
2026-07-27 12:52:02 +02:00
4b9c23472c SAP OM: org units, jobs, positions, and a derived reporting line
The org structure was three fixed tables — divisions -> departments ->
teams — with people hanging directly off them and a hand-maintained
manager_id. The depth was therefore wired into the schema: an Abteilungsleitung
could not exist without a migration, and a team directly under a Bereich not
at all. That is what this replaces.

The SAP OM object types, one table each:

  O  org_units             recursive over parent_id
  C  jobs                  catalogue, so many positions can share a job
  S  om_positions          belongs to exactly one org unit
  P  employees             existing table
  A012 om_positions.is_chief          "ist Leiter von"
  A008 position_assignments           "Inhaber ist", time-dependent

Two consequences worth stating, because they are the point of the exercise:

- GF/Bereich/Abteilung/Team are now a label (unit_type), not a structure.
  Adding a fifth level, or hanging a team straight off a Bereich, becomes a
  data question rather than a migration.
- Nobody hangs off an org unit any more: person -> position -> unit. A
  vacancy stops being its own concept — it is a position with no current
  assignment.

The reporting line is derived rather than stored: an ordinary position
reports to the chief of its own unit, a chief to the chief of the parent
unit, and if that chief is vacant or on a long-term absence it keeps
climbing. An unfilled Abteilungsleitung therefore needs no special case —
it is simply skipped. Both ids come back, formal and acting, so the UI can
show a stand-in as a stand-in instead of passing it off as the real manager.

The rule exists twice, as om_reporting_lines() in SQL and
resolveReportingLines() in TypeScript, because the as-of chart computes it
per date in the app and a round trip per date change would buy nothing. Two
copies drift silently — the org chart would just show a different manager
than the export — so an integration test runs both over the whole roster and
requires identical answers, plus that every line terminates at the top.

Unit tests cover the rule itself: unfilled levels, several absent levels in
a row, nobody above, a chief who also leads the parent unit, and a cycle in
parent_id, which is an ordinary column an import could get wrong.

Additive so far. The old tables still stand and the app still reads them;
the cut-over follows.
2026-07-27 12:47:14 +02:00
392 changed files with 45995 additions and 6803 deletions

View File

@@ -15,6 +15,3 @@ npm-debug.log*
*.tsbuildinfo
.scratch_*
.scratch_shots
supabase/.branches
supabase/.temp
supabase/snippets

View File

@@ -1,14 +1,65 @@
# Public: safe to expose to the browser (inlined into the client bundle at
# build time). Anon-key access is still fully gated by RLS server-side.
NEXT_PUBLIC_SUPABASE_URL=
NEXT_PUBLIC_SUPABASE_ANON_KEY=
# ── Datenbank ────────────────────────────────────────────────────────
#
# Die Datenbank läuft als eigener Container (Dienst `db` in
# docker-compose.yml). Diese drei Werte richten ihn ein:
#
# POSTGRES_PASSWORD das des Verwalters (postgres) — nur für Migrationen,
# Sicherungen und Wartung
# APP_DB_PASSWORD das der Anwendungsrolle alpenwerk_app
# POSTGRES_DB Name der Datenbank; Vorgabe alpenwerk
#
# Beide Passwörter selbst erzeugen: `openssl rand -base64 24`
#
# Sie werden nur beim **allerersten** Start ausgewertet, solange das
# Datenverzeichnis leer ist. Ein späterer Wechsel braucht ein
# `alter role … password …` in der laufenden Datenbank.
POSTGRES_PASSWORD=
APP_DB_PASSWORD=
POSTGRES_DB=alpenwerk
POSTGRES_USER=postgres
# Server-only: bypasses Row Level Security entirely. Never prefix with
# NEXT_PUBLIC_, never import outside lib/supabase/admin.ts (guarded by
# `import "server-only"`), never log or return in an API response.
SUPABASE_SERVICE_ROLE_KEY=
# Womit die Anwendung sich verbindet. Im Compose-Netz heisst die Datenbank
# `db`; von aussen ist sie nicht erreichbar, es gibt bewusst keinen Port.
#
# Die Rolle in diesem String darf KEIN BYPASSRLS haben: fehlt der
# Sitzungskontext, sollen die Policies nichts zurückgeben statt alles.
# `alpenwerk_app` wird in deploy/db-init genau so angelegt.
DATABASE_URL=postgresql://alpenwerk_app:<APP_DB_PASSWORD>@db:5432/alpenwerk
# Im Compose-Netz läuft Postgres ohne TLS — die Verbindung verlässt den
# Server nicht. Bei einer Datenbank ausserhalb diesen Wert entfernen.
DATABASE_SSL=false
# Verbindungen im Pool; Vorgabe 10.
DATABASE_POOL_MAX=
# Shared secret Vercel Cron sends as `Authorization: Bearer <value>` when it
# calls /api/cron/apply-pending-changes (set the same value in the Vercel
# project's env vars). Generate with e.g. `openssl rand -hex 32`.
# Der **direkte** Zugang für Migrationen (scripts/migrate.mjs). Als Verwalter,
# weil Migrationen Schemaänderungen vornehmen, die die Anwendungsrolle nicht
# darf. Bei Betrieb über docker compose wird er nicht gebraucht — der Dienst
# `migrate` setzt ihn selbst aus POSTGRES_PASSWORD zusammen.
MIGRATE_DATABASE_URL=
# ── Anmeldung (Auth.js + Microsoft Entra ID) ─────────────────────────
# Schlüssel, mit dem das Sitzungscookie signiert und verschlüsselt wird.
# Erzeugen mit `npx auth secret` oder `openssl rand -base64 32`. Ein Wechsel
# meldet alle ab — was im Ernstfall genau das gewünschte Mittel ist.
AUTH_SECRET=
# Aus der Anwendungsregistrierung im Entra-Portal: Anwendungs-ID (Client),
# ein Geheimnis daraus, und der Aussteller mit der Verzeichnis-ID (Mandant).
#
# Der Aussteller darf NICHT auf /common/ stehen bleiben — sonst könnte sich
# jedes Microsoft-Konto anmelden, auch ein privates.
AUTH_MICROSOFT_ENTRA_ID_ID=
AUTH_MICROSOFT_ENTRA_ID_SECRET=
AUTH_MICROSOFT_ENTRA_ID_ISSUER=https://login.microsoftonline.com/<verzeichnis-id>/v2.0
# Nur nötig, wenn die Anwendung hinter einem Reverse Proxy unter einer
# anderen Adresse erreichbar ist, als sie selbst sieht. Ohne diesen Wert baut
# Auth.js die Rückruf-Adresse aus den Request-Headern.
AUTH_URL=
# Gemeinsames Geheimnis, mit dem sich der nächtliche Lauf ausweist: der
# `cron`-Container schickt es als `Authorization: Bearer <wert>` an
# /api/cron/apply-pending-changes. Ohne angemeldete Person gibt es keine
# Sitzung, an der die Route den Aufruf prüfen könnte.
# Erzeugen mit: openssl rand -hex 32
CRON_SECRET=

View File

@@ -29,25 +29,45 @@ jobs:
- name: Typecheck
run: npm run typecheck
# Catches the drift that `tsc` cannot: lib/supabase/types.ts is
# hand-written, so a migration adding a column leaves it silently stale.
# Fängt die Abweichung, die `tsc` nicht sehen kann: lib/types.ts wird von
# Hand gepflegt, eine Migration mit einer neuen Spalte lässt sie also
# stillschweigend veralten.
- name: Schema/Typen-Abgleich
run: npm run types:check
- name: Unit- und Komponententests
run: npm test
# Ohne Umgebungsvariablen: seit dem Wegfall der Browser-Anbindung wird
# zur Bauzeit nichts mehr aus der Umgebung gelesen, und das Abbild ist
# für jede Umgebung dasselbe.
- name: Build
run: npm run build
env:
# Read at module scope by the Supabase browser client, so the build
# needs them present — never the real project's values.
NEXT_PUBLIC_SUPABASE_URL: http://127.0.0.1:54321
NEXT_PUBLIC_SUPABASE_ANON_KEY: build-time-placeholder
integration:
name: Integrationstests (echtes Postgres)
migrationen:
name: Migrationen auf leerer Datenbank
runs-on: ubuntu-latest
# Derselbe Stand wie im Betrieb. Ein eigener Dienst statt einer fremden
# Plattform — die Datenbank gehört seit dem Umzug zum Projekt.
services:
postgres:
image: postgres:17-alpine
env:
POSTGRES_PASSWORD: ci
POSTGRES_DB: alpenwerk
ports:
- 5432:5432
options: >-
--health-cmd "pg_isready -U postgres"
--health-interval 5s
--health-timeout 5s
--health-retries 20
env:
MIGRATE_DATABASE_URL: postgresql://postgres:ci@postgres:5432/alpenwerk
DATABASE_SSL: "false"
steps:
- uses: actions/checkout@v4
@@ -58,33 +78,117 @@ jobs:
- run: npm ci
- uses: supabase/setup-cli@v1
with:
version: latest
# Applies every migration to a fresh database — which also means a
# migration that cannot be replayed from scratch fails here rather than
# on a restore or a new environment.
- name: Supabase starten
run: supabase start
# `-o env` emits API_URL / ANON_KEY / SERVICE_ROLE_KEY; the app expects
# them under its own names.
- name: Testumgebung schreiben
# Das Abbild des Runners bringt keinen Postgres-Client mit; der
# Schritt darunter ruft aber psql. Ohne das bricht er mit
# "psql: command not found" ab, bevor die erste Datei laeuft.
- name: psql bereitstellen
run: |
supabase status -o env \
--override-name api.url=NEXT_PUBLIC_SUPABASE_URL \
--override-name auth.anon_key=NEXT_PUBLIC_SUPABASE_ANON_KEY \
--override-name auth.service_role_key=SUPABASE_SERVICE_ROLE_KEY \
| grep -E '^(NEXT_PUBLIC_SUPABASE_URL|NEXT_PUBLIC_SUPABASE_ANON_KEY|SUPABASE_SERVICE_ROLE_KEY)=' \
| tr -d '"' > .env.test.local
apt-get update -qq
apt-get install -y -qq --no-install-recommends postgresql-client
psql --version
- name: Seed
run: node --env-file=.env.test.local supabase/seed.ts
# Was das Schema von der Umgebung erwartet: die Anwendungsrolle ohne
# BYPASSRLS, zwei Erweiterungen und die Attrappe des `auth`-Schemas, ohne
# die sich die Migrationen von Juni 2026 nicht abspielen lassen.
- name: Rollen, Erweiterungen, auth-Attrappe
env:
PGPASSWORD: ci
APP_DB_PASSWORD: ci-anwendungsrolle
run: |
for f in deploy/db-init/*.sql; do
echo "── $f"
psql -v ON_ERROR_STOP=1 -h postgres -U postgres -d alpenwerk -f "$f"
done
- name: Integrationstests
run: npm run test:integration
# Der eigentliche Zweck dieses Jobs: jede Migration muss sich auf einer
# leeren Datenbank abspielen lassen. Eine, die das nicht kann, fällt hier
# auf — und nicht beim Wiederherstellen einer Sicherung oder beim
# Aufsetzen einer neuen Umgebung.
- name: Migrationen einspielen
run: node scripts/migrate.mjs
- name: Supabase-Logs bei Fehlschlag
if: failure()
run: supabase status && docker ps -a
# Zweiter Lauf: die Buchführung muss greifen. Meldet er etwas anderes als
# „nichts anzuwenden", verbucht der Läufer nicht richtig — und ein
# Ausrollen spielte Migrationen doppelt ein.
- name: Zweiter Lauf ist ein Nichts
run: |
ausgabe=$(node scripts/migrate.mjs)
echo "$ausgabe"
echo "$ausgabe" | grep -q "^Nichts anzuwenden" \
|| { echo "Der zweite Lauf wollte erneut anwenden — die Buchführung greift nicht."; exit 1; }
# Dass die Migrationen durchlaufen, heisst nicht, dass das Ergebnis
# stimmt. Bis hierher prüft dieser Job nur, dass keine Datei abbricht —
# und genau daran ist ein Fehler vorbeigekommen: vier Tabellen aus dem
# August (Kostenstellen, On-/Offboarding) standen ohne Zeilenschutz da,
# weil sie sich auf den Ereignis-Trigger `ensure_rls` verliessen, den
# eine spätere Migration erst anlegt. Alle Dateien liefen sauber durch,
# die Policies standen im Katalog, und ausgewertet wurde keine davon.
#
# Deshalb wird ab hier der **Zustand** geprüft, nicht der Durchlauf.
# Nachgezogen hat das 20260908100000; dort steht dieselbe Gegenprobe.
# Sie läuft aber nur einmal, beim Anwenden jener Datei. Der Schritt hier
# läuft bei jedem Push gegen eine frisch aufgebaute Datenbank und fängt
# deshalb auch die *nächste* Tabelle, die es wieder vergisst.
- name: Zugriffsschutz nach dem Lauf
env:
PGPASSWORD: ci
run: |
set -euo pipefail
frage() {
psql -v ON_ERROR_STOP=1 -h postgres -U postgres -d alpenwerk -At -c "$1"
}
# relkind in ('r','p'): gewöhnliche und partitionierte Tabellen.
ohne_rls=$(frage "
select coalesce(string_agg(c.relname, ', ' order by c.relname), '')
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public'
and c.relkind in ('r', 'p')
and not c.relrowsecurity")
# RLS ohne Policy ist nicht offen, sondern leer — kein Leck, aber
# eine Tabelle, aus der nie etwas zurückkommt.
ohne_policy=$(frage "
select coalesce(string_agg(c.relname, ', ' order by c.relname), '')
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public'
and c.relkind in ('r', 'p')
and not exists (select 1 from pg_policy p where p.polrelid = c.oid)")
# Das Netz selbst: fehlt oder schläft es, ist die nächste neue
# Tabelle wieder ungeschützt.
netz=$(frage "
select count(*) from pg_event_trigger
where evtname = 'ensure_rls' and evtenabled <> 'D'")
fehler=0
if [ -n "$ohne_rls" ]; then
echo "Ohne Row Level Security: $ohne_rls"
fehler=1
fi
if [ -n "$ohne_policy" ]; then
echo "Mit Row Level Security, aber ohne jede Policy: $ohne_policy"
fehler=1
fi
if [ "$netz" != "1" ]; then
echo "Der Ereignis-Trigger ensure_rls fehlt oder ist abgeschaltet."
fehler=1
fi
if [ "$fehler" -ne 0 ]; then
echo
echo "Jede Tabelle in public braucht RLS und mindestens eine Policy."
echo "Nachziehen in einer neuen Migration, nicht in einer bereits angewendeten."
exit 1
fi
echo "Zugriffsschutz vollstaendig: jede Tabelle mit RLS und Policy, ensure_rls aktiv."
# Die Integrationstests brauchen einen befüllten Bestand; der Seed lag
# in der abgelösten Umgebung und ist noch nicht nachgezogen (siehe
# README, offene Punkte). Bis dahin laufen sie gegen eine erreichbare
# Datenbank von Hand, nicht hier.

191
.github/workflows/deploy.yml vendored Normal file
View File

@@ -0,0 +1,191 @@
name: Deploy
# Warum diese Datei unter .github/workflows liegt und nicht unter .gitea/:
#
# Gitea Actions liest `.gitea/workflows`, **und nur wenn dieses Verzeichnis
# fehlt**, ersatzweise `.github/workflows`. Ein neu angelegtes `.gitea/`
# würde also ci.yml stillschweigend abschalten — der Lauf verschwände
# einfach, ohne Fehlermeldung. Solange beide Dateien hier liegen, sieht Gitea
# beide. (Auf GitHub bliebe dieser Workflow hängen: es gibt dort keinen
# Runner mit dem Label `self-hosted`. Das Repository liegt aber ohnehin auf
# git.elycon.solutions.)
# Nur von Hand auslösbar (Actions → Deploy → „Run workflow").
#
# Lief einmal bei jedem Push auf master. Das ist zurückgenommen: die
# Voraussetzungen dafür sind nicht erfüllt — es sind keine Secrets hinterlegt,
# und ob der Job-Container den Docker-Dienst des Hosts überhaupt erreicht, ist
# ungeprüft. Bei jedem Push zu scheitern erzieht dazu, rote Läufe zu
# übersehen; dann lieber gar nicht starten.
#
# Nach dem Umzug auf den eigenen db-Container stimmt hier ausserdem noch
# nicht alles: die Secrets unten kennen die neuen Werte (POSTGRES_PASSWORD,
# APP_DB_PASSWORD) nicht, und Migrationen laufen jetzt über den Dienst
# `migrate` statt über einen eigenen Node-Schritt. Wer das wieder scharf
# schaltet, muss beides nachziehen.
on:
workflow_dispatch:
# Zwei Pushes kurz hintereinander sollen nicht zwei Deploys übereinander
# fahren. Der laufende wird **nicht** abgebrochen — mitten im `docker compose
# up` abgeschnitten zu werden ist der eine Zustand, den man nicht will.
concurrency:
group: deploy-${{ github.ref }}
cancel-in-progress: false
jobs:
deploy:
name: Migrationen und Container
# `ubuntu-latest`, weil der vorhandene Runner (elycon-runner-01) genau
# diese Bezeichnung anbietet — neben `docker`. Ein Label, das kein Runner
# führt, lässt den Lauf wortlos in der Warteschlange stehen: kein Fehler,
# keine Meldung, nur „Waiting".
runs-on: ubuntu-latest
steps:
# ── Vorprüfung ──────────────────────────────────────────────────
#
# Dieser Job läuft in einem Container, den der Runner startet — nicht
# auf dem Server selbst. Ob er den Docker-Dienst des **Hosts** erreicht,
# hängt davon ab, wie der Runner konfiguriert ist; von aussen ist das
# nicht zu sehen. Statt es zu raten, wird es hier gemessen und im
# Fehlerfall gesagt, was fehlt — sonst scheitert der Lauf erst drei
# Schritte später an einer Meldung, die niemandem weiterhilft.
- name: Erreicht dieser Job den Docker-Dienst des Servers?
run: |
set -u
if ! command -v docker >/dev/null 2>&1; then
echo 'Im Job-Container gibt es kein "docker".'
echo
echo "Zwei Wege:"
echo " a) Im Runner (config.yaml) ein Abbild verwenden, das die Docker-CLI"
echo " mitbringt, und den Socket durchreichen — siehe DEPLOYMENT.md §5."
echo " b) Statt lokal per SSH auf den Server ausrollen."
exit 1
fi
if ! docker info >/dev/null 2>&1; then
echo "Docker-CLI vorhanden, aber kein Dienst erreichbar."
echo
echo "Dem Job-Container fehlt der Socket des Hosts. In der config.yaml des"
echo "Runners:"
echo " container:"
echo " options: -v /var/run/docker.sock:/var/run/docker.sock"
echo " valid_volumes: [/var/run/docker.sock]"
echo "Danach den Runner neu starten. Alternative: Deploy per SSH."
exit 1
fi
docker compose version
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
# Nur was der Migrationsläufer braucht (`pg`), nicht der ganze Baum:
# gebaut wird die Anwendung im Container, nicht hier.
- name: Abhängigkeiten
run: npm ci --omit=dev --ignore-scripts
# ── .env aus den Gitea-Secrets ──────────────────────────────────
#
# Nicht die .env vom Server lesen: der Job läuft in einem eigenen
# Container, und dessen Dateisystem ist nicht das des Hosts. Die Werte
# kommen deshalb aus den Repository-Secrets und werden hier
# zusammengesetzt. Sie landen in keinem Abbild — docker compose reicht
# sie zur Laufzeit an den Container weiter.
- name: .env schreiben
env:
DATABASE_URL: ${{ secrets.DATABASE_URL }}
MIGRATE_DATABASE_URL: ${{ secrets.MIGRATE_DATABASE_URL }}
AUTH_SECRET: ${{ secrets.AUTH_SECRET }}
AUTH_URL: ${{ secrets.AUTH_URL }}
AUTH_MICROSOFT_ENTRA_ID_ID: ${{ secrets.AUTH_MICROSOFT_ENTRA_ID_ID }}
AUTH_MICROSOFT_ENTRA_ID_SECRET: ${{ secrets.AUTH_MICROSOFT_ENTRA_ID_SECRET }}
AUTH_MICROSOFT_ENTRA_ID_ISSUER: ${{ secrets.AUTH_MICROSOFT_ENTRA_ID_ISSUER }}
CRON_SECRET: ${{ secrets.CRON_SECRET }}
run: |
set -euo pipefail
fehlend=""
for name in DATABASE_URL MIGRATE_DATABASE_URL AUTH_SECRET AUTH_URL \
AUTH_MICROSOFT_ENTRA_ID_ID AUTH_MICROSOFT_ENTRA_ID_SECRET \
AUTH_MICROSOFT_ENTRA_ID_ISSUER CRON_SECRET; do
eval "wert=\${$name:-}"
[ -n "$wert" ] || fehlend="$fehlend $name"
done
if [ -n "$fehlend" ]; then
echo "Diese Secrets fehlen im Repository (Settings → Actions → Secrets):$fehlend"
exit 1
fi
# printf statt echo: ein Wert, der mit - beginnt, wäre sonst ein Schalter.
{
printf 'DATABASE_URL=%s\n' "$DATABASE_URL"
printf 'AUTH_SECRET=%s\n' "$AUTH_SECRET"
printf 'AUTH_URL=%s\n' "$AUTH_URL"
printf 'AUTH_MICROSOFT_ENTRA_ID_ID=%s\n' "$AUTH_MICROSOFT_ENTRA_ID_ID"
printf 'AUTH_MICROSOFT_ENTRA_ID_SECRET=%s\n' "$AUTH_MICROSOFT_ENTRA_ID_SECRET"
printf 'AUTH_MICROSOFT_ENTRA_ID_ISSUER=%s\n' "$AUTH_MICROSOFT_ENTRA_ID_ISSUER"
printf 'CRON_SECRET=%s\n' "$CRON_SECRET"
} > .env
chmod 600 .env
# ── Migrationen ─────────────────────────────────────────────────
#
# Vor dem Neustart, nicht danach: der neue Code erwartet das neue
# Schema. Umgekehrt liefe die neue Anwendung kurz gegen das alte und
# fiele über fehlende Spalten.
#
# Erst zeigen, was ansteht — das steht dann im Protokoll des Laufs, auch
# wenn danach etwas schiefgeht.
- name: Ausstehende Migrationen zeigen
env:
MIGRATE_DATABASE_URL: ${{ secrets.MIGRATE_DATABASE_URL }}
run: node scripts/migrate.mjs --dry-run
- name: Migrationen anwenden
env:
MIGRATE_DATABASE_URL: ${{ secrets.MIGRATE_DATABASE_URL }}
run: node scripts/migrate.mjs
# ── Container ───────────────────────────────────────────────────
#
# Läuft gegen den Docker-Dienst des Hosts (der Runner-Container hat
# dessen Socket eingehängt). Der Projektname wird ausdrücklich gesetzt:
# sonst leitet ihn Compose vom Verzeichnisnamen ab, und der ist im
# Arbeitsverzeichnis des Runners ein anderer als bei der ersten
# Installation von Hand — es entstünde ein zweiter Stapel daneben,
# während der alte weiterläuft.
- name: Bauen und starten
env:
COMPOSE_PROJECT_NAME: ${{ vars.COMPOSE_PROJECT_NAME || 'alpenwerk-hr' }}
run: |
set -euo pipefail
docker compose build
docker compose up -d --remove-orphans
# ── Nachweis ────────────────────────────────────────────────────
#
# Ohne diesen Schritt gilt ein Deploy als erfolgreich, sobald der
# Container *gestartet* ist — auch wenn die Anwendung darin sofort
# abstürzt. Gewartet wird auf den Healthcheck aus dem Dockerfile
# (GET /login), nicht auf „läuft".
- name: Warten, bis die Anwendung antwortet
env:
COMPOSE_PROJECT_NAME: ${{ vars.COMPOSE_PROJECT_NAME || 'alpenwerk-hr' }}
run: |
set -euo pipefail
for versuch in $(seq 1 30); do
zustand=$(docker compose ps --format '{{.Health}}' app | head -1)
case "$zustand" in
healthy) echo "Gesund nach $versuch Versuchen."; exit 0 ;;
unhealthy) echo "Container meldet unhealthy."; break ;;
esac
sleep 4
done
echo "Anwendung ist nicht gesund geworden. Letzte Ausgaben:"
docker compose ps
docker compose logs --tail 80 app
exit 1
- name: Aufräumen
if: always()
run: rm -f .env

24
.gitignore vendored
View File

@@ -34,23 +34,21 @@ yarn-error.log*
.env*
!.env.example
# vercel
.vercel
# typescript
*.tsbuildinfo
next-env.d.ts
# supabase CLI local dev (generated, project-machine-specific)
/supabase/.branches
/supabase/.temp
/supabase/snippets
# scratch output of `npm run types:generate`, for comparing against the
# hand-written lib/supabase/types.ts — never itself imported
/lib/supabase/types.generated.ts
# local scratch scripts/screenshots (ad-hoc verification against a real or
# seeded DB — can carry HR data or use SUPABASE_SERVICE_ROLE_KEY; never commit)
# Kladden und Bildschirmfotos aus der Handprüfung — können Personendaten
# oder Zugangsdaten enthalten; nie committen.
.scratch_*
/.scratch_shots/
# Datenbank-Sicherungen (enthalten Personendaten) – nie committen.
.backups/
# Datenabzuege aus dem Umzug – enthalten Personendaten
# Datenbank-Abzuege – enthalten Personendaten, nie committen.
*.sql.gz
/*.sql

View File

@@ -1,31 +1,74 @@
# Deployment mit Docker
# Deployment
Dieser Guide beschreibt, wie die App (bisher auf Vercel deployed, siehe
`vercel.json`) stattdessen als Docker-Container auf einem beliebigen Server
läuft.
Die Anwendung läuft als Docker-Container auf einem eigenen Linux-Server,
zusammen mit ihrer Datenbank. Das Abbild ist umgebungsneutral — es gibt
keine Werte, die beim Bauen eingebacken werden; alles kommt zur Laufzeit
aus `.env`.
Zu klären, bevor es losgeht: die Umgebungsvariablen aus
[Abschnitt 1](#1-env-anlegen), die Umleitungs-URI in der
Entra-Registrierung, und dass eine neue Person nach ihrer ersten Anmeldung
eine `profiles`-Zeile braucht (siehe [docs/entra-sso.md](docs/entra-sso.md)).
## Was wird containerisiert – und was nicht
- **Containerisiert:** nur die Next.js-App selbst (`Dockerfile`).
- **Nicht containerisiert:** Supabase (Datenbank + Auth). Die App verbindet
sich per URL/Key zu einem bestehenden Supabase-Projekt (Cloud oder
selbst gehostet) – das bleibt unverändert. `supabase/` in diesem Repo ist
nur die lokale Dev-/Migrations-Umgebung (`supabase start`), kein Teil des
Deployments.
- **Ersetzt:** der Vercel-Cron-Job aus `vercel.json` (täglich 03:00 Uhr,
ruft `/api/cron/apply-pending-changes` auf, um fällige Versetzungen/
Beförderungen/Karenz/Reorg-Änderungen zu übernehmen). Da es außerhalb von
Vercel kein Vercel-Cron gibt, übernimmt das im `docker-compose.yml`
enthaltene `cron`-Sidecar-Container diese Aufgabe mit demselben Schema
und demselben Bearer-Secret, das die Route bereits erwartet.
- **Containerisiert:** die Next.js-App (`Dockerfile`) **und die Datenbank**
(Dienst `db`, `postgres:17-alpine`). Beide zusammen in
`docker-compose.yml`; die Daten liegen im benannten Volume `db-daten`.
- **Die Datenbank gehört zum Projekt.** Was eine gehostete Plattform sonst
beisteuert, bringt `deploy/db-init/` mit: die Anwendungsrolle ohne
BYPASSRLS, die zwei benutzten Erweiterungen und eine Attrappe des
`auth`-Schemas, die nur die Migrationen von Juni 2026 brauchen.
- Läuft die Datenbank woanders (Azure Flexible Server, RDS, eigenes Blech),
genügt es, `DATABASE_URL` dorthin zeigen zu lassen und den `db`-Dienst nicht
zu starten. Die Anwendung merkt keinen Unterschied.
- **Ebenfalls nicht containerisiert:** die Anmeldung. Sie läuft über
Microsoft Entra ID; die App hält nur das Sitzungscookie (Auth.js). Es gibt
keinen Anmeldedienst, der mit ausgerollt werden müsste.
- **Der nächtliche Lauf** ist ein eigener Container (`cron`): täglich 03:00
Uhr ruft er `/api/cron/apply-pending-changes` auf, um fällige Versetzungen,
Beförderungen, Karenz- und Reorg-Änderungen zu übernehmen. Ausgewiesen wird
der Aufruf über `CRON_SECRET` — es gibt dabei keine angemeldete Person.
## Betrieb im Firmennetz — zwei Dinge vorab
Die App läuft intern, aber sie ist **nicht** von der Aussenwelt unabhängig.
Beides vor der Installation klären, sonst scheitert es am Ende an der
Firewall:
**1. Der Server braucht ausgehenden Zugang.** Eingehend aus dem Internet
nichts, ausgehend zwingend:
| Ziel | Wofür | Ohne das |
|---|---|---|
| `login.microsoftonline.com` (443) | Auth.js tauscht den Anmeldecode **serverseitig** gegen ein Token und lädt die Konfiguration des Ausstellers | keine Anmeldung möglich |
Dass die Anmeldung im Browser der Person stattfindet, genügt **nicht** — der
Tausch von Code gegen Token läuft vom Server aus. Liegt die VM in einem
abgeschotteten Netz, braucht es dafür einen Proxy.
Die Datenbank taucht hier nicht mehr auf: sie läuft als Container daneben, im
selben Compose-Netz. Nach aussen geht dafür nichts.
**2. HTTPS ist Pflicht, auch intern.** Entra ID akzeptiert `http` nur für
`localhost`. Der praktikable Weg ohne öffentliche Erreichbarkeit: ein
**öffentlicher DNS-Name, der auf die private Adresse zeigt** (z. B.
`hr.elycon.solutions` → `10.x.x.x`) und ein Zertifikat über die
DNS-Challenge. Das ist zulässig, verbreitet, und liefert ein regulär
vertrauenswürdiges Zertifikat, ohne dass der Server je aus dem Internet
erreichbar ist.
Beispielkonfiguration: [`deploy/Caddyfile`](deploy/Caddyfile).
Die Alternative — selbst signiertes Zertifikat — bedeutet, es auf jedem
Arbeitsplatz als vertrauenswürdig zu hinterlegen. Bei zwei Personen machbar,
bei zwanzig nicht.
## Voraussetzungen
- Docker + Docker Compose (v2, das im Docker Desktop/Docker Engine
enthaltene `docker compose`) auf dem Zielserver.
- Ein bestehendes Supabase-Projekt mit den Migrationen aus
`supabase/migrations/` bereits eingespielt (`supabase db push` bzw. wie
bisher).
- Docker + Docker Compose (v2, das in Docker Engine enthaltene
`docker compose`) auf dem Zielserver. Sonst nichts — weder Node noch psql;
was gebraucht wird, kommt aus Containern.
## 1. `.env` anlegen
@@ -37,21 +80,24 @@ Werte eintragen:
| Variable | Woher |
|---|---|
| `NEXT_PUBLIC_SUPABASE_URL` | Supabase-Projekt → Settings → API |
| `NEXT_PUBLIC_SUPABASE_ANON_KEY` | Supabase-Projekt → Settings → API |
| `SUPABASE_SERVICE_ROLE_KEY` | Supabase-Projekt → Settings → API (geheim!) |
| `POSTGRES_PASSWORD` | selbst erzeugen: `openssl rand -base64 24` — das des Verwalters |
| `APP_DB_PASSWORD` | selbst erzeugen — das der Anwendungsrolle `alpenwerk_app` |
| `DATABASE_URL` | `postgresql://alpenwerk_app:<APP_DB_PASSWORD>@db:5432/alpenwerk`. Die Rolle darf **kein** `BYPASSRLS` haben — `deploy/db-init` legt sie genau so an |
| `DATABASE_SSL` | `false` im Compose-Netz; die Verbindung verlässt den Server nicht |
| `AUTH_SECRET` | selbst generieren: `openssl rand -base64 32` |
| `AUTH_MICROSOFT_ENTRA_ID_ID` | Entra-Portal → App-Registrierung → Übersicht |
| `AUTH_MICROSOFT_ENTRA_ID_SECRET` | Entra-Portal → Zertifikate & Geheimnisse (nur einmal sichtbar!) |
| `AUTH_MICROSOFT_ENTRA_ID_ISSUER` | `https://login.microsoftonline.com/<verzeichnis-id>/v2.0` |
| `CRON_SECRET` | selbst generieren: `openssl rand -hex 32` |
Details zur Entra-Registrierung: [`docs/entra-sso.md`](docs/entra-sso.md).
Wichtig zum Verständnis:
- `NEXT_PUBLIC_*`-Variablen werden **beim Build** in das Browser-Bundle
eingebacken (Next.js-Verhalten, nicht Docker-spezifisch). Ändern sich
diese Werte, muss das Image **neu gebaut** werden – ein reiner Container-
Neustart reicht nicht.
- `SUPABASE_SERVICE_ROLE_KEY` und `CRON_SECRET` sind Server-only-Secrets.
Sie werden bewusst **nicht** als Build-Arg übergeben (das würde sie im
Image-Layer-History sichtbar machen), sondern erst zur Laufzeit über
`env_file` injiziert.
- **Nichts davon wird in das Image eingebacken.** Es gibt keine
`NEXT_PUBLIC_*`-Variablen mehr; alle Werte liest die Anwendung zur Laufzeit
über `env_file`. Eine Änderung braucht deshalb nur einen Neustart, keinen
neuen Build — und dasselbe Image läuft in Test und Produktion.
- `.env` steht schon in `.gitignore` – nicht committen.
## 2. Bauen und lokal testen
@@ -82,35 +128,193 @@ docker compose up -d --build
```
Alternative für CI/CD (Image einmal bauen, überall pullen): Image in einer
Registry (GHCR, Docker Hub, …) bauen und pushen, auf dem Server nur
Registry bauen und pushen, auf dem Server nur
`docker compose pull && docker compose up -d` ausführen. Dafür in
`docker-compose.yml` zusätzlich `image: <registry>/<name>:<tag>` setzen und
den Build in der CI-Pipeline mit den `--build-arg`-Werten für
`NEXT_PUBLIC_*` laufen lassen.
`docker-compose.yml` zusätzlich `image: <registry>/<name>:<tag>` setzen.
Build-Argumente braucht es dabei **keine**: das Abbild enthält keine
umgebungsabhängigen Werte mehr, alles kommt zur Laufzeit aus `.env`.
Dasselbe Abbild läuft damit in Test und Produktion.
### Bei einer leeren Datenbank
Der `db`-Container legt beim ersten Start Rollen und Erweiterungen an; das
Schema kommt danach aus den Migrationen:
```bash
docker compose up -d db
docker compose run --rm migrate # legt Tabellen, Funktionen, Policies an
docker compose up -d --build
```
`migrate` steht im Profil `tools` und läuft bei `docker compose up` nicht mit.
Auf dem Host wird dafür weder Node noch psql gebraucht — nur Docker.
### Was am `auth`-Schema übrigbleibt
`deploy/db-init/01-auth-attrappe.sql` legt ein leeres `auth`-Schema an. Es wird
im Betrieb **nicht** gebraucht: kein Fremdschlüssel, keine Policy, keine
Spaltenvorgabe verweist darauf (geprüft). Gebraucht wird es nur beim Abspielen
der Migrationen von Juni 2026, die damals noch an `auth.users` hingen. Die
Alternative wäre, jene Dateien umzuschreiben — also Geschichte zu fälschen: sie
beschreiben, was damals galt.
## 4. Reverse Proxy + HTTPS
Next.js selbst sollte laut den offiziellen Docs **nicht** direkt exponiert
werden – ein Reverse Proxy übernimmt TLS, Rate-Limiting und Request-
Validierung. Beispiel mit [Caddy](https://caddyserver.com/) (automatisches
HTTPS via Let's Encrypt):
Validierung.
```caddyfile
# /etc/caddy/Caddyfile
hr.example.com {
reverse_proxy localhost:3000
}
Fertige Konfiguration: [`deploy/Caddyfile`](deploy/Caddyfile) — mit
DNS-Challenge, weil der Server aus dem Internet nicht erreichbar ist (siehe
[oben](#betrieb-im-firmennetz--zwei-dinge-vorab)).
```bash
sudo cp deploy/Caddyfile /etc/caddy/Caddyfile
sudo systemctl reload caddy
```
`docker-compose.yml` published Port 3000 aktuell auf den Host – bei
Verwendung eines Reverse Proxys auf demselben Host kann das Publishing auf
`127.0.0.1:3000:3000` eingeschränkt werden, damit der Container-Port nicht
direkt von außen erreichbar ist.
`docker-compose.yml` veröffentlicht Port 3000 bewusst nur auf
`127.0.0.1` — die App ist also ausschliesslich über den Proxy erreichbar,
nicht daneben unverschlüsselt.
## 5. Updates ausrollen
Zusätzlich in die `.env`:
```
AUTH_URL=https://hr.elycon.solutions
```
Ohne diesen Wert baut Auth.js seine Rückruf-Adresse aus dem, was der
Container sieht — und das ist hinter dem Proxy nicht der Name, den der
Browser benutzt hat.
## 5. Automatisch ausrollen bei einem Push (Gitea Actions)
Ein Push auf `master` baut und startet die Anwendung auf dem Server neu.
Zuständig ist [`.github/workflows/deploy.yml`](.github/workflows/deploy.yml).
> **Warum `.github/` und nicht `.gitea/`:** Gitea Actions liest
> `.gitea/workflows` — und nur wenn dieses Verzeichnis **fehlt**, ersatzweise
> `.github/workflows`. Ein neu angelegtes `.gitea/workflows/` würde also
> `ci.yml` stillschweigend abschalten. Solange beide Dateien unter `.github/`
> liegen, sieht Gitea beide.
### a) Der Runner
Verwendet wird der bestehende, globale Runner **`elycon-runner-01`** (act_runner
v0.2.11, Labels `docker` und `ubuntu-latest`). Ein eigener ist nicht nötig.
Beide Workflows laufen deshalb auf `ubuntu-latest`. **Ein Label, das kein
Runner führt, lässt den Lauf wortlos in der Warteschlange stehen** — kein
Fehler, keine Meldung, nur „Waiting". Das ist der häufigste Grund, warum
scheinbar nichts passiert.
#### Der Job läuft im Container, nicht auf dem Server
Das ist die Stelle, an der es klemmen kann. act_runner startet je Job einen
eigenen Container; der Docker-Socket des **Hosts** ist darin nur, wenn der
Runner so konfiguriert ist:
```yaml
# config.yaml des Runners
container:
options: -v /var/run/docker.sock:/var/run/docker.sock
valid_volumes:
- /var/run/docker.sock
```
Zusätzlich muss das Job-Abbild die Docker-CLI mitbringen (die üblichen
`runner-images`/`catthehacker`-Abbilder tun das).
Der erste Schritt des Deploy-Workflows prüft genau das und bricht mit einer
Anleitung ab, wenn etwas fehlt — statt drei Schritte später an einer Meldung zu
scheitern, mit der niemand etwas anfangen kann.
> Der durchgereichte Socket gibt dem Job faktisch Wurzelrechte auf dem Host.
> Bei einem Deploy-Runner ist das der Zweck der Übung, aber es heisst auch: wer
> in dieses Repository schreiben darf, darf auf diesem Server alles. Bei einem
> **globalen** Runner gilt das für jedes Repository der Instanz, das denselben
> Socket benutzt. Ist das zu weit gefasst, ist der Weg über SSH der richtige:
> ein Schlüssel als Repository-Secret, der nur auf den einen Server und nur auf
> das Deploy-Verzeichnis zeigt.
### b) Secrets hinterlegen
Gitea → Repository → *Settings* → *Actions* → *Secrets*. Dieselben Werte wie in
[Abschnitt 1](#1-env-anlegen); der Workflow baut daraus zur Laufzeit die `.env`
und löscht sie danach wieder.
| Secret | Anmerkung |
|---|---|
| `DATABASE_URL` | Verbindung der Anwendungsrolle — die benutzt die Anwendung |
| `MIGRATE_DATABASE_URL` | Zugang als Verwalter — nur für die Migrationen |
| `AUTH_SECRET` | |
| `AUTH_URL` | z. B. `https://hr.elycon.solutions` |
| `AUTH_MICROSOFT_ENTRA_ID_ID` | |
| `AUTH_MICROSOFT_ENTRA_ID_SECRET` | |
| `AUTH_MICROSOFT_ENTRA_ID_ISSUER` | |
| `CRON_SECRET` | |
Warum zwei Verbindungsstrings: der Transaktions-Pooler bricht bei einer
Migration ab, die mehrere Anweisungen in einer Transaktion bündelt. Migrationen
gehören über die direkte Verbindung, der laufende Betrieb über den Pooler.
Zusätzlich unter *Variables* (kein Secret, nur eine Einstellung):
| Variable | Vorgabe | Wofür |
|---|---|---|
| `COMPOSE_PROJECT_NAME` | `alpenwerk-hr` | Muss zum bestehenden Stapel passen — sonst entsteht ein zweiter daneben |
Den bestehenden Namen zeigt auf dem Server:
```bash
docker compose ls
```
### c) Was der Lauf tut
1. `.env` aus den Secrets schreiben (fehlt eines, bricht er mit Namen ab).
2. **Migrationen anwenden** — erst `--dry-run` fürs Protokoll, dann echt.
3. `docker compose build` und `up -d` gegen den Docker-Dienst des Hosts.
4. Auf `healthy` warten (bis zu zwei Minuten). Wird die Anwendung nicht gesund,
schlägt der Lauf fehl und hängt die letzten 80 Logzeilen an.
5. `.env` wieder löschen.
Der Workflow ist **nicht** an `ci.yml` gekoppelt: ein Push auf `master` rollt
aus, auch wenn die Tests parallel noch laufen. Soll erst nach grünen Tests
ausgerollt werden, gehört der `deploy`-Job mit `needs: [check]` in `ci.yml` —
dann allerdings braucht der Runner auch das Label, mit dem `check` läuft.
## 5a. Migrationen
Eingespielt werden sie von [`scripts/migrate.mjs`](scripts/migrate.mjs) —
demselben Läufer, den auch der Deploy benutzt:
```bash
node --env-file=.env scripts/migrate.mjs --dry-run # was stünde an
node --env-file=.env scripts/migrate.mjs # anwenden
```
Buch geführt wird in `migrationen.schema_migrations`: eine Zeile je
angewendeter Datei, mit ihrem Text. Der Läufer wendet nur an, was dort
fehlt.
> **Einmalig, im August 2026 bereits erledigt:** Die Migrationen wurden bis
> dahin von Hand eingespielt, die Buchführungstabelle existierte gar nicht. Ein
> automatischer Lauf hätte deshalb alle 65 Dateien erneut gegen die
> produktive Datenbank gespielt — inklusive `initial_schema` und der
> OM-Umstellung. Vor dem Einschalten wurde einmal
> `node scripts/migrate.mjs --baseline` gefahren: das verbucht alles Vorhandene
> als angewendet, **ohne es auszuführen**. Wer eine weitere Umgebung aufsetzt,
> deren Datenbank schon steht, braucht denselben Schritt.
## 5b. Updates von Hand ausrollen
Falls der Runner nicht läuft oder ein Stand ausser der Reihe gebraucht wird:
```bash
git pull
node --env-file=.env scripts/migrate.mjs
docker compose build
docker compose up -d
```
@@ -119,13 +323,8 @@ Kurzer Downtime-Moment beim Neustart des `app`-Containers ist bei dieser
Single-Instance-Compose-Konfiguration normal. Für Zero-Downtime-Deployments
wäre eine zweite Instanz + Load Balancer nötig (siehe Abschnitt 6).
Datenbank-Migrationen (`supabase/migrations/*.sql`) werden weiterhin über
die Supabase CLI gegen das Supabase-Projekt gefahren, unabhängig vom
App-Deployment:
```bash
supabase db push
```
Der Migrationsschritt steht bewusst **vor** dem Neubau: der neue Code erwartet
das neue Schema, und umgekehrt liefe die neue Anwendung kurz gegen das alte.
## 6. Hinweis bei mehreren Replicas
@@ -145,12 +344,35 @@ Single-Instance-Compose-Konfiguration ist das nicht nötig.
## Troubleshooting
- **Login-Redirect-Loop / `proxy.ts` verhält sich falsch:** meist falsche
`NEXT_PUBLIC_SUPABASE_URL`/`ANON_KEY` – Image neu bauen (siehe oben, diese
Werte sind eingebacken).
- **Push gemacht, aber kein Lauf startet:** meist die Labels. Der Lauf steht
dann in Gitea unter *Actions* als „Waiting" — ohne Fehlermeldung, weil kein
Runner das verlangte Label anbietet. Beide Workflows verlangen
`ubuntu-latest`; `elycon-runner-01` führt es. Welche Labels registriert sind,
zeigt Gitea → *Site Administration* → *Actions* → *Runners*.
- **Deploy läuft, aber es entsteht ein zweiter Stapel:** `COMPOSE_PROJECT_NAME`
passt nicht zum bestehenden. Auf dem Server `docker compose ls` — der dort
gelistete Name gehört als Variable ins Repository. Bis dahin läuft die alte
Instanz weiter und beansprucht Port 3000; die neue scheitert daran.
- **`Cannot connect to the Docker daemon` im Deploy:** dem Runner-Container
fehlt der Socket. Er braucht `-v /var/run/docker.sock:/var/run/docker.sock`.
- **Migration schlägt im Deploy fehl:** der Lauf bricht ab, bevor Container
angefasst werden — die alte Version läuft also weiter. Die fehlgeschlagene
Datei wurde vollständig zurückgerollt und **nicht** verbucht; nach der
Korrektur reicht ein erneuter Push.
- **Anmeldung endet auf `/login?error=…`:** die Umleitungs-URI in der
Entra-Registrierung muss exakt
`https://<host>/api/auth/callback/microsoft-entra-id` lauten. Steht die
Anwendung hinter einem Reverse Proxy unter einer anderen Adresse, als sie
selbst sieht, zusätzlich `AUTH_URL` setzen.
- **Angemeldet, aber sofort zurück auf `/login?error=no_hr_access`:** die
Anmeldung hat funktioniert, es fehlt die Freischaltung. Es braucht eine
`profiles`-Zeile mit `role = 'hr'` und `is_active = true` auf derselben
Kennung, die in `app_users` steht.
- **Cron läuft nicht:** `docker compose logs cron` – prüft, ob
`/etc/crontabs/root` korrekt geschrieben wurde und ob `CRON_SECRET` in
`.env` gesetzt ist (leer/fehlend führt serverseitig zu `401`).
- **Healthcheck rot:** `docker compose logs app` – meist fehlende/falsche
Supabase-Env-Variablen zur Laufzeit (`SUPABASE_SERVICE_ROLE_KEY`,
Server-Komponenten).
- **Healthcheck rot:** `docker compose logs app` – meist `DATABASE_URL`
fehlend oder nicht erreichbar. Der Pool baut die Verbindung erst beim
ersten Zugriff auf, der Fehler steht deshalb im Log der Anfrage, nicht im
Start-Log.

View File

@@ -12,13 +12,13 @@ WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
# Public env vars are inlined into the client bundle at build time, so they
# must be available here, not just at runtime. Values are passed in via
# --build-arg (see DEPLOYMENT.md).
ARG NEXT_PUBLIC_SUPABASE_URL
ARG NEXT_PUBLIC_SUPABASE_ANON_KEY
ENV NEXT_PUBLIC_SUPABASE_URL=$NEXT_PUBLIC_SUPABASE_URL
ENV NEXT_PUBLIC_SUPABASE_ANON_KEY=$NEXT_PUBLIC_SUPABASE_ANON_KEY
# Keine Build-Argumente mehr: es gibt keine NEXT_PUBLIC_*-Werte mehr, die in
# das Browser-Bundle eingebacken würden. Datenbank und Anmeldung sprechen
# ausschliesslich den Server an, und dessen Zugangsdaten kommen zur Laufzeit.
#
# Dadurch ist dieses Abbild umgebungsneutral: einmal gebaut, in Test und
# Produktion dasselbe. Vorher hätte jede Umgebung ihr eigenes gebraucht — und
# eine Baustrecke, die die Zugangsdaten schon zum Bauen kennt.
ENV NEXT_TELEMETRY_DISABLED=1
RUN npm run build

111
README.md
View File

@@ -24,11 +24,13 @@ auf explizit aktivierte HR-Benutzer:innen beschränkt (siehe
`node_modules/next/dist/docs/` konsultieren; sie sind maßgeblich, ältere
Anleitungen im Netz beschreiben teils überholte APIs.
- React 19, TypeScript
- Supabase (Postgres, Auth, RLS) — Datenhaltung liegt vollständig in
Supabase, nicht im Next.js-Prozess.
- PostgreSQL, angesprochen über Kysely und `pg` — die Datenhaltung liegt in
der Datenbank, nicht im Next.js-Prozess. Der Zugriff läuft ausschliesslich
über `withUser()` (`lib/db/`), das den Sitzungskontext setzt.
- Auth.js gegen Microsoft Entra ID — keine eigenen Passwörter.
- Tailwind CSS v4
- Vitest — Unit- (Node), Komponenten- (jsdom) und Integrationstests
(gegen ein lokales Supabase)
(gegen eine erreichbare Datenbank)
## Setup
@@ -38,14 +40,14 @@ cp .env.example .env.local # Werte eintragen, siehe unten
npm run dev
```
Für lokale Supabase-Entwicklung (statt gegen ein Cloud-Projekt):
Für eine lokale Datenbank genügt der Container aus `docker-compose.yml`:
```bash
supabase start # startet lokalen Postgres/Auth/Studio-Stack
docker compose up -d db
docker compose run --rm migrate # spielt db/migrations/ ein
```
`supabase/config.toml` und `.env.test.local` sind bereits auf die
Standard-Ports der lokalen Supabase-CLI abgestimmt.
Danach zeigt `DATABASE_URL` in `.env.local` auf diese Datenbank.
## Umgebungsvariablen
@@ -54,14 +56,18 @@ Liste. Kurzfassung:
| Variable | Sichtbarkeit | Zweck |
|---|---|---|
| `NEXT_PUBLIC_SUPABASE_URL` | Browser + Server | Supabase-Projekt-URL |
| `NEXT_PUBLIC_SUPABASE_ANON_KEY` | Browser + Server | Anon-Key, RLS-gebunden |
| `SUPABASE_SERVICE_ROLE_KEY` | **Nur Server** | Umgeht RLS vollständig — niemals im Browser-Bundle, niemals loggen |
| `DATABASE_URL` | Nur Server | PostgreSQL-Verbindung. Die Rolle darf **kein** `BYPASSRLS` haben |
| `DATABASE_SSL` | Nur Server | `false` für lokal/CI ohne TLS |
| `AUTH_SECRET` | Nur Server | Signiert und verschlüsselt das Sitzungscookie |
| `AUTH_MICROSOFT_ENTRA_ID_ID` | Nur Server | Anwendungs-ID der Entra-Registrierung |
| `AUTH_MICROSOFT_ENTRA_ID_SECRET` | Nur Server | Client-Geheimnis dazu |
| `AUTH_MICROSOFT_ENTRA_ID_ISSUER` | Nur Server | Aussteller mit Mandanten-ID — nicht `common` |
| `CRON_SECRET` | Nur Server | Schützt `/api/cron/apply-pending-changes` |
`NEXT_PUBLIC_*`-Werte werden beim Build in das Client-Bundle eingebacken —
eine Änderung erfordert einen Rebuild, nicht nur einen Neustart (relevant
für Docker-Deployments, siehe unten).
**Es gibt keine `NEXT_PUBLIC_*`-Variablen mehr.** Nichts wird in das
Browser-Bundle eingebacken, weil der Browser mit nichts ausser der Anwendung
selbst spricht. Ein Docker-Abbild ist damit umgebungsneutral: einmal gebaut,
überall dasselbe — vorher brauchte jede Umgebung ihr eigenes.
## Scripts
@@ -73,9 +79,10 @@ für Docker-Deployments, siehe unten).
| `npm run lint` | ESLint (`eslint-config-next`, Flat Config) |
| `npm run typecheck` | `tsc --noEmit` |
| `npm run test` | Vitest, Unit-Tests (`tests/unit/**`) |
| `npm run test:integration` | Vitest gegen eine echte (lokale) Supabase-Instanz — braucht `supabase start` und `.env.test.local` |
| `npm run test:integration` | Vitest gegen eine erreichbare Datenbank; überspringt sich ohne `DATABASE_URL` |
| `npm run test:e2e` | Playwright |
| `npm run check` | lint + typecheck + test + build in Folge |
| `npm run migrate` | Ausstehende Migrationen einspielen (`--dry-run`, `--baseline`) |
| `npm run check` | lint + typecheck + types:check + test + build in Folge — dieselben Schritte wie der CI-Job „check" |
## Sicherheitsprinzipien
@@ -84,11 +91,16 @@ für Docker-Deployments, siehe unten).
Ersatzkontrolle.
- **Ein Rollenmodell:** `profiles.role = 'hr'` + `profiles.is_active = true`,
geprüft über die SQL-Funktion `is_hr_user()`. Kein Sub-Rollensystem —
siehe [`docs/data-model.md`](docs/data-model.md#zugriffsmodell).
- **Service-Role-Key ist server-only.** Einzige Verwendung:
`lib/supabase/admin.ts`, geschützt durch `import "server-only"` (macht
einen versehentlichen Client-Import zu einem Build-Fehler statt einem
Laufzeitproblem).
siehe [`docs/datenkatalog.md`](docs/datenkatalog.md#zugriffsschutz).
- **Es gibt keinen privilegierten Zugang mehr.** Der Dienstschlüssel, der RLS
aushebelte, ist ersatzlos entfallen; auch der nächtliche Lauf benutzt
dieselbe Rolle ohne `BYPASSRLS`. Was ohne angemeldete Person laufen muss,
steht als `SECURITY DEFINER`-Funktion in der Datenbank und prüft dort
selbst, was es tut.
- **Jede Abfrage läuft in einer Transaktion mit gesetztem Sitzungskontext.**
Die Kysely-Instanz wird nicht exportiert — der einzige Weg an die Datenbank
ist `withUser()` (`lib/db/index.ts`), und eine ESLint-Regel verbietet den
Import von `pg` ausserhalb von `lib/db/`.
- **Audit-Log ist transaktional in der Datenbank**, nicht im App-Code: jede
mutierende SQL-Funktion schreibt ihren `audit_log`-Eintrag in derselben
Transaktion wie die Änderung selbst. Details und Prüfung siehe
@@ -101,51 +113,50 @@ für Docker-Deployments, siehe unten).
`/api/cron/apply-pending-changes` wendet wirksam gewordene, zukunftsdatierte
Änderungen an (`pending_org_changes` → `apply_due_pending_changes()`).
- **Auf Vercel:** `vercel.json` definiert den täglichen Schedule; Vercel Cron
sendet `Authorization: Bearer <CRON_SECRET>` automatisch, wenn
`CRON_SECRET` in den Projekt-Env-Vars gesetzt ist.
- **Außerhalb von Vercel (Docker):** kein Vercel Cron verfügbar — siehe
[`DEPLOYMENT.md`](DEPLOYMENT.md) für den Cron-Sidecar-Container, der
denselben Endpoint mit demselben Schema aufruft.
- Den Zeitplan hält der `cron`-Container aus `docker-compose.yml`: täglich
03:00 Uhr, mit `Authorization: Bearer <CRON_SECRET>`.
- Fehlt `CRON_SECRET` oder stimmt der Header nicht, antwortet die Route mit
`401` (nicht `500` — bewusst, siehe `tests/unit/security.test.ts`).
## Supabase-Hinweise
## Datenbank
- Schema-Quelle der Wahrheit: `supabase/migrations/`. Menschlich lesbare
Zusammenfassung: [`docs/data-model.md`](docs/data-model.md).
- Migrationen einspielen: `supabase db push` (gegen das verlinkte Projekt)
bzw. `supabase start` + automatische Anwendung für lokale Entwicklung.
- `supabase/seed.ts` und `.env.test.local` sind nur für lokale
Entwicklung/Tests gedacht, nie für ein Produktivprojekt verwenden.
- Schema-Quelle der Wahrheit: `db/migrations/`. Menschlich lesbare Fassung,
aus der laufenden Datenbank erzeugt:
[`docs/datenkatalog.md`](docs/datenkatalog.md).
- Migrationen einspielen: `npm run migrate`. Der Läufer wendet nur die
fehlenden Dateien an, jede in ihrer eigenen Transaktion, und führt darüber
Buch in `migrationen.schema_migrations`.
- `lib/types.ts` wird von Hand gepflegt. `npm run types:check` hält sie
Spalte für Spalte gegen die Migrationen.
## Testing
- `npm run test` — schnell, keine externen Abhängigkeiten, läuft in CI.
- `npm run test:integration` — braucht eine laufende lokale Supabase-Instanz
(`supabase start`) und `.env.test.local`; prüft RLS-Verhalten end-to-end
(siehe `tests/integration/authorization.test.ts` für das HR-Only-Zugriffs-
modell).
- `npm run test:integration` — braucht eine erreichbare Datenbank
(`DATABASE_URL`). Geprüft werden Regeln, die es zweimal gibt: einmal als
SQL, einmal als TypeScript. Ohne `DATABASE_URL` überspringen sich die
Dateien, statt mit einem Verbindungsfehler abzubrechen.
- `npm run test:e2e` — Playwright gegen einen laufenden Dev-/Preview-Server.
## Deployment
Siehe [`DEPLOYMENT.md`](DEPLOYMENT.md) für Docker-basiertes Deployment
(Dockerfile, docker-compose.yml, Reverse-Proxy/TLS, Cron-Ersatz, Updates).
Für Vercel: `vercel.json` ist bereits vorhanden; Env-Vars im
Vercel-Projekt setzen (siehe oben).
Siehe [`DEPLOYMENT.md`](DEPLOYMENT.md): Anwendung und Datenbank als Container,
Reverse-Proxy/TLS, der nächtliche Lauf, Migrationen und Updates.
## Known TODOs vor Produktivbetrieb
- **Content-Security-Policy fehlt noch** (`next.config.ts` setzt bewusst
keine CSP — Skript-/Style-/Connect-Quellen sind noch nicht vollständig
inventarisiert; ungeprüft geraten zu setzen riskiert, Hydration oder den
Supabase-Client stillschweigend zu brechen).
- **Lokale Scratch-Artefakte** (`.scratch_*`, `.scratch_shots/`) enthalten
Screenshots/Hilfsskripte aus einer früheren manuellen Verifikation und
liegen noch im Arbeitsverzeichnis. Sie sind jetzt über `.gitignore`
ausgeschlossen; vor einem Produktiv-Handover sollten sie durchgesehen und
bei Bedarf gelöscht werden.
- **Content-Security-Policy läuft im Nur-Bericht-Modus** (`next.config.ts`).
Erzwungen wird sie erst, wenn die Meldungen sauber sind — eine geratene,
erzwungene Richtlinie blendet die Anwendung für alle aus.
- **Seed für die Integrationstests fehlt.** Er lag in der abgelösten
Umgebung. Zwei der drei Integrationstests vergleichen Regeln über den
gesamten Bestand und brauchen dafür Daten; bis der Seed nachgezogen ist,
laufen sie nur gegen eine bereits befüllte Datenbank, nicht in der CI.
- **Sicherheitsprüfung des heutigen Aufbaus steht aus** — siehe
[`docs/security-review.md`](docs/security-review.md).
- **Bildschirmfotos unter `.scratch_shots/`** stammen aus einer früheren
Handprüfung. Sie sind über `.gitignore` ausgeschlossen; vor der Übergabe
durchsehen und löschen.
- **Kein granulareres Rollenmodell** — aktuell HR-only (alles-oder-nichts).
Falls z. B. eine reine Lese-Rolle künftig gebraucht wird, gehört die
Erweiterung in eine neue Migration (`is_hr_user()`/RLS-Policies), nicht in

View File

@@ -1,24 +1,86 @@
"use server";
import { redirect } from "next/navigation";
import { createClient } from "@/lib/supabase/server";
import { AuthError } from "next-auth";
import { signIn, signOut } from "@/auth";
export async function login(formData: FormData) {
const email = String(formData.get("email") ?? "");
const password = String(formData.get("password") ?? "");
// Zwei Anmeldewege, und der zweite ist auf Zeit.
//
// **Entra ID ist der Hauptweg.** Was der Mandant vorgibt — Mehrfaktor,
// bedingter Zugriff, Sperrung beim Austritt — gilt nur auf diesem Weg. Ein
// zweiter Weg daneben hebelt all das aus, und deshalb stand hier bis zum
// 08.09.2026, dass es ihn bewusst nicht gibt.
//
// **Warum es ihn jetzt trotzdem gibt.** Fünf Mitarbeiterinnen des Kunden
// (@manner.com) sollen die Anwendung testen. Manner hat einen eigenen
// Entra-Mandanten; eine Gasteinladung müsste deren IT einrichten und dauert
// Wochen. Die Daten im System sind zu diesem Zeitpunkt synthetisch.
//
// **Was den Weg begrenzt** — nichts davon steht hier, alles in der Datenbank
// (Migration 20260908120000), weil eine Regel im Anwendungscode die Regel
// wäre, die sich umgehen lässt:
//
// • Zwang zum Wechsel beim ersten Mal; solange er aussteht, liefert
// is_hr_user() false und damit gibt keine einzige Policy eine Zeile her
// • sieben Tage Frist für einen nie benutzten Zugang
// • Sperre für 15 Minuten nach fünf Fehlversuchen
// • Enddatum 08.10.2026, als Prüfbedingung festgenagelt
// (chk_passwort_pfad_endet) — danach nimmt die Anmeldung kein Passwort
// mehr an, ohne dass sich jemand erinnern muss
//
// **Vor den echten Manner-Daten muss der Passwortpfad weg sein.** Das ist die
// Bedingung, unter der er entstanden ist, nicht eine Empfehlung.
//
// Die Herkunft muss hier nicht aus dem Request geholt werden: Auth.js baut die
// Rückruf-Adresse selbst und akzeptiert nur Ziele auf demselben Host. Ein
// untergeschobener Host läuft also weiterhin ins Leere.
const supabase = await createClient();
const { error } = await supabase.auth.signInWithPassword({ email, password });
export async function signInWithEntra() {
// Kehrt nicht zurück: signIn löst eine Weiterleitung aus, und die wirft in
// Next.js.
await signIn("microsoft-entra-id", { redirectTo: "/" });
}
if (error) {
redirect("/login?error=invalid_credentials");
export type AnmeldeZustand = { fehler: string | null };
/**
* Anmeldung mit E-Mail und Passwort.
*
* Es gibt **eine** Fehlermeldung für jeden Fehlschlag. Ob die Adresse
* unbekannt, das Passwort falsch, das Konto gesperrt oder die Frist abgelaufen
* ist, steht im Protokoll und nicht auf dem Bildschirm: das Anmeldeformular
* steht offen im Internet, und eine Meldung, die zwischen „gibt es nicht" und
* „falsches Passwort" unterscheidet, ist ein Verzeichnis der Belegschaft.
* app_passwort_pruefen() nennt aus demselben Grund keinen Grund.
*/
export async function anmeldenMitPasswort(
_zustand: AnmeldeZustand,
formular: FormData
): Promise<AnmeldeZustand> {
const email = String(formular.get("email") ?? "").trim();
const passwort = String(formular.get("passwort") ?? "");
if (!email || !passwort) {
return { fehler: "Bitte E-Mail-Adresse und Passwort eingeben." };
}
redirect("/");
try {
await signIn("passwort", { email, passwort, redirectTo: "/" });
} catch (fehler) {
// Bei Erfolg wirft signIn die Weiterleitung von Next.js. Die darf hier
// **nicht** hängenbleiben, sonst endet die Anmeldung auf der Anmeldeseite,
// obwohl das Cookie längst gesetzt ist. Nur ein AuthError ist ein
// Fehlschlag; alles andere gehört weitergereicht.
if (fehler instanceof AuthError) {
return { fehler: "E-Mail-Adresse oder Passwort stimmt nicht." };
}
throw fehler;
}
// Unerreichbar — signIn kehrt bei Erfolg nicht zurück. Steht da, weil der
// Typprüfer einen Rückgabewert auf jedem Pfad verlangt.
return { fehler: null };
}
export async function logout() {
const supabase = await createClient();
await supabase.auth.signOut();
redirect("/login");
await signOut({ redirectTo: "/login" });
}

View File

@@ -1,22 +1,67 @@
"use server";
import { revalidatePath } from "next/cache";
import { sanitizeIlikeTerm } from "@/lib/supabase/query";
import { createClient } from "@/lib/supabase/server";
import type { CollectiveAgreement, Database, NoteCategory, RelationshipType, Weekday, WorkerType } from "@/lib/supabase/types";
type ActionResult = { success: boolean; error?: string };
type MutationFn = keyof Database["public"]["Functions"];
import { currentUserId } from "@/lib/auth/session";
import { withUser } from "@/lib/db";
import { callFunction, runMutation, type ActionResult, type MutationFn } from "@/lib/db/rpc";
import { OFFBOARDING_PUNKTE } from "@/lib/offboarding";
import { ONBOARDING_PUNKTE } from "@/lib/onboarding";
import type { CollectiveAgreement, DienstwagenArt, NoteCategory, PaygradeType, RelationshipType, Weekday, WorkerType } from "@/lib/types";
async function callRpc(fn: MutationFn, payload: Record<string, unknown>, revalidate: string[]): Promise<ActionResult> {
const supabase = await createClient();
const { error } = await supabase.rpc(fn, { payload });
if (error) return { success: false, error: error.message };
const result = await runMutation(await currentUserId(), fn, payload);
if (!result.success) return result;
for (const path of revalidate) revalidatePath(path);
return { success: true };
return result;
}
/**
* Ist diese Personalnummer noch frei?
*
* ── Warum das trotz der Prüfung in der Datenbank hier steht ──────────
*
* `hire_employee` weist eine vergebene Nummer ab, und das bleibt die
* verbindliche Prüfung: zwischen dieser Frage und dem Anlegen können Sekunden
* liegen, und in denen kann jemand anderes dieselbe Nummer vergeben. Der
* Unique-Index ist die einzige Stelle, die das sicher ausschliesst.
*
* Nur kommt diese Abweisung ganz am Ende — nach Position, Vertrag,
* Angehörigen, Notfallkontakt, sechs Schritten Eingabe. Die Nummer steht im
* *ersten* Feld des *ersten* Schritts. Wer sie vertippt, erfährt es
* frühestens nach fünf Minuten und darf dann suchen, welche der Angaben
* gemeint war.
*
* Deshalb hier die frühe Auskunft und dort die Entscheidung. Es ist keine
* doppelte Wahrheit, sondern dieselbe Frage zu zwei Zeitpunkten — und wenn
* die späte Antwort einmal abweicht, gewinnt sie.
*
* Kein `ActionResult`: eine vergebene Nummer ist kein Fehler des Aufrufs,
* sondern die Antwort auf die Frage.
*/
export async function personalnummerVergeben(nummer: number): Promise<{ vergeben: boolean; name?: string }> {
if (!Number.isInteger(nummer) || nummer <= 0) return { vergeben: false };
return withUser(await currentUserId(), async (tx) => {
const treffer = await tx
.selectFrom("employees")
.select(["first_name", "last_name"])
.where("personnel_number", "=", nummer)
.executeTakeFirst();
// Der Name wird mitgegeben, weil „bereits vergeben" allein die Frage
// aufwirft, an wen — und die Antwort ist meistens der Grund: dieselbe
// Person ist schon angelegt, oder es war ein Zahlendreher.
return treffer ? { vergeben: true, name: `${treffer.first_name} ${treffer.last_name}` } : { vergeben: false };
});
}
export async function hireEmployee(payload: {
/**
* Wird eingegeben, nicht vergeben.
*
* Sie muss mit Loga und Interflex übereinstimmen; eine hier selbst gezogene
* Nummer wäre dort unbekannt und die Person hätte in drei Systemen zwei
* Nummern. Die Datenbank weist eine bereits vergebene Nummer ab.
*/
personnel_number: number;
first_name: string;
last_name: string;
title_prefix?: string[];
@@ -24,6 +69,24 @@ export async function hireEmployee(payload: {
gender: "m" | "w";
birth_date: string;
sv_nummer?: string;
/**
* Die **private** Adresse, freiwillig.
*
* Sie war einmal Pflicht, weil die Spalte NOT NULL war — für eine private
* Angabe die falsche Vorgabe: wer keine hat, musste eine erfinden. Bleibt
* eindeutig, wenn angegeben.
*/
email?: string;
/**
* Die **dienstliche** Adresse, freiwillig und eindeutig.
*
* Eigenes Feld neben der privaten, weil nur diese das Haus verlassen darf:
* der Export für die Mitarbeiterbefragung geht an einen fremden Anbieter,
* der in unserem Namen Einladungen verschickt.
*/
company_email?: string;
/** Kennung im Lernsystem Cornerstone. Freiwillig. */
cornerstone_id?: string;
phone?: string;
position_id?: string;
team_id?: string;
@@ -34,39 +97,117 @@ export async function hireEmployee(payload: {
contract_end_date?: string;
employment_type?: "Vollzeit" | "Teilzeit";
weekly_hours?: number;
paygrade?: "A" | "B" | "C" | "D" | "E" | "F";
paygrade?: PaygradeType;
source: "Intern" | "Extern";
worker_type?: WorkerType;
collective_agreement?: CollectiveAgreement;
work_days?: Weekday[];
is_betriebsrat?: boolean;
has_dienstwagen?: boolean;
dienstwagen_art?: DienstwagenArt | null;
emergency_contact_name?: string;
emergency_contact_phone?: string;
emergency_contact_relation?: string;
is_laterale_fuehrung?: boolean;
is_c_level?: boolean;
/** Form der Beschäftigung — chk_mitarbeiterart. Leer heisst „unverändert". */
mitarbeiterart?: string;
has_kuendigungsschutz?: boolean;
/** Nur mit dem Kennzeichen zusammen — so verlangt es chk_kuendigungsschutz_bis. */
kuendigungsschutz_bis?: string | null;
/** Ebenfalls nur mit dem Kennzeichen — chk_kuendigungsschutz_grund. */
kuendigungsschutz_grund?: string | null;
kuendigungsschutz_ab?: string | null;
ist_beguenstigt_behindert?: boolean;
/** Nur mit dem Kennzeichen — chk_behinderung. Als Text, wie er aus dem Feld kommt. */
behinderung_grad?: string | null;
behinderung_ab?: string | null;
behinderung_bis?: string | null;
}): Promise<ActionResult & { employeeId?: string }> {
const supabase = await createClient();
const { data, error } = await supabase.rpc("hire_employee", { payload });
if (error) return { success: false, error: error.message };
revalidatePath("/employees");
revalidatePath("/");
revalidatePath("/positions");
return { success: true, employeeId: data as string };
// Einzige Mutation, deren Rückgabewert gebraucht wird: die neue
// Personen-Kennung, damit die Oberfläche direkt auf die Akte springen kann.
try {
const employeeId = await withUser(await currentUserId(), async (tx) => {
const id = (await callFunction(tx, "hire_employee", payload as Record<string, unknown>)) as string;
// In derselben Transaktion: eine Einstellung ohne Checkliste wäre eine
// halb erfasste Einstellung, und sie später nachzureichen hiesse, dass
// jemand daran denken muss.
await callFunction(tx, "start_onboarding", { employee_id: id, item_keys: ONBOARDING_PUNKTE.map((x) => x.key) });
return id;
});
revalidatePath("/employees");
revalidatePath("/");
revalidatePath("/positions");
return { success: true, employeeId: employeeId as string };
} catch (err) {
return { success: false, error: err instanceof Error ? err.message : "Unbekannter Fehler." };
}
}
export async function terminateEmployee(payload: {
employee_id: string;
exit_date: string;
exit_reason: string;
/**
* Freiwillig oder unfreiwillig — leer heisst „nicht erfasst".
*
* Eigene Angabe und nicht aus `exit_reason` abgeleitet: die einvernehmliche
* Auflösung kann von beiden Seiten ausgehen (siehe lib/beendigung.ts).
*/
austrittsart?: string;
note?: string;
}): Promise<ActionResult> {
return callRpc("terminate_employee", payload, [`/employees/${payload.employee_id}`, "/employees", "/"]);
// No Show ist kein Austritt im gewohnten Sinn — die Person hat nie
// angefangen. Dafür gibt es nichts offzuboarden: keinen IT-Zugang, der
// eingerichtet wurde, keine GKK-Anmeldung, kein Dienstzettel. Die Liste
// entstünde leer und wäre ein Etikett ohne Inhalt.
if (payload.exit_reason === "No Show") {
return callRpc("terminate_employee", payload, [`/employees/${payload.employee_id}`, "/employees", "/"]);
}
try {
await withUser(await currentUserId(), async (tx) => {
await callFunction(tx, "terminate_employee", payload as unknown as Record<string, unknown>);
// In derselben Transaktion: ein Austritt ohne Checkliste wäre ein
// halb erfasster Austritt, und sie später anzulegen hiesse, dass
// jemand daran denken muss.
await callFunction(tx, "start_offboarding", {
employee_id: payload.employee_id,
item_keys: OFFBOARDING_PUNKTE.map((x) => x.key),
});
});
} catch (err) {
return { success: false, error: err instanceof Error ? err.message : "Unbekannter Fehler." };
}
for (const path of [`/employees/${payload.employee_id}`, "/employees", "/"]) revalidatePath(path);
return { success: true };
}
/** Einen Punkt der Offboarding-Checkliste festhalten — Haken, Wert oder Kommentar. */
export async function setOffboardingTask(payload: {
employee_id: string;
item_key: string;
erledigt?: boolean;
wert?: string | null;
kommentar?: string | null;
}): Promise<ActionResult> {
return callRpc("set_offboarding_task", payload, [`/employees/${payload.employee_id}`]);
}
/** Legt die Offboarding-Checkliste nachträglich an — für Austritte von vor dieser Liste. */
export async function startOffboarding(employeeId: string): Promise<ActionResult> {
return callRpc(
"start_offboarding",
{ employee_id: employeeId, item_keys: OFFBOARDING_PUNKTE.map((x) => x.key) },
[`/employees/${employeeId}`]
);
}
export async function transferEmployee(payload: {
employee_id: string;
effective_date: string;
new_team_id: string;
new_title?: string;
/** Die Zielplanstelle; Bereich, Abteilung und Team ergeben sich aus ihrer Einheit. */
target_position_id: string;
}): Promise<ActionResult> {
return callRpc("transfer_employee", payload, [`/employees/${payload.employee_id}`, "/employees"]);
}
@@ -75,7 +216,14 @@ export async function promoteEmployee(payload: {
employee_id: string;
effective_date: string;
new_title: string;
new_paygrade?: "A" | "B" | "C" | "D" | "E" | "F";
new_paygrade?: PaygradeType;
/**
* Nur, wenn die Beförderung zugleich auf eine andere Planstelle führt.
*
* Fehlt sie, bleibt die Person auf ihrer bisherigen — das ist der andere
* der beiden Fälle, nicht ein vergessenes Feld.
*/
target_position_id?: string;
}): Promise<ActionResult> {
return callRpc("promote_employee", payload, [`/employees/${payload.employee_id}`, "/employees"]);
}
@@ -103,6 +251,10 @@ export async function recordKarenzReturn(payload: {
return_date: string;
employment_mode: "unverändert" | "Vollzeit" | "Teilzeit";
weekly_hours?: number;
/** Wiedereingliederungs- oder Elternteilzeit, wenn reduziert zurückgekehrt wird. */
reduction_reason?: string;
/** Ende der Teilzeit, falls bekannt — nur mit einem Grund zusammen. */
teilzeit_bis?: string;
}): Promise<ActionResult> {
return callRpc("record_karenz_return", payload, [`/employees/${payload.employee_id}`, "/employees", "/"]);
}
@@ -112,13 +264,76 @@ export async function changeEmployeeData(payload: {
effective_date: string;
person: Record<string, unknown>;
contract: Record<string, unknown>;
// `role` trägt seit 20260917120000 auch `source`. Wechselt sie von
// „Extern" auf „Intern", schreibt change_employee_data zusätzlich das
// Ereignis „Übernahme" — der umgekehrte Weg erzeugt keines.
role: Record<string, unknown>;
}): Promise<ActionResult> {
return callRpc("change_employee_data", payload, [`/employees/${payload.employee_id}`, "/employees"]);
}
export async function rehireEmployee(payload: { employee_id: string; rehire_date: string }): Promise<ActionResult> {
return callRpc("rehire_employee", payload, [`/employees/${payload.employee_id}`, "/employees", "/"]);
/**
* `position_id` ist Pflicht — die Datenbankfunktion verlangt sie seit jeher.
*
* Die alte Stelle taugt nicht als stille Vorgabe: sie kann inzwischen besetzt
* oder ausgelaufen sein. Sie fehlte hier nur in der Signatur, weshalb jede
* Wiedereinstellung an einer Meldung scheiterte, die im Dialog nicht zu
* beheben war.
*/
export async function rehireEmployee(payload: {
employee_id: string;
company_email?: string;
cornerstone_id?: string;
rehire_date: string;
position_id: string;
/**
* Die Stammdaten, wie sie der Assistent zeigt — alle freiwillig.
*
* Fehlt ein Schlüssel, bleibt der bestehende Wert stehen. Das hält den
* schlanken Aufruf (nur Datum und Planstelle) am Leben und erlaubt dem
* Assistenten trotzdem, den ganzen Satz zu schicken, ohne dass danach eine
* zweite Transaktion nötig wäre — siehe Migration 20260917130000.
*/
[feld: string]: unknown;
}): Promise<ActionResult> {
try {
await withUser(await currentUserId(), async (tx) => {
await callFunction(tx, "rehire_employee", payload as unknown as Record<string, unknown>);
// Auch bei der Wiedereinstellung: Dienstzettel, Bankverbindung und
// E-Card sind wieder zu erledigen. Die Punkte von damals stehen noch da
// und bleiben stehen — start_onboarding legt nur an, was fehlt, statt
// einen alten Haken zu löschen. Was wirklich neu zu tun ist, entscheidet
// HR an der Liste; ein Programm an ihrer Stelle würde raten.
await callFunction(tx, "start_onboarding", {
employee_id: payload.employee_id,
item_keys: ONBOARDING_PUNKTE.map((x) => x.key),
});
});
} catch (err) {
return { success: false, error: err instanceof Error ? err.message : "Unbekannter Fehler." };
}
for (const path of [`/employees/${payload.employee_id}`, "/employees", "/"]) revalidatePath(path);
return { success: true };
}
/** Einen Punkt der Checkliste festhalten — Haken, Wert oder Kommentar. */
export async function setOnboardingTask(payload: {
employee_id: string;
item_key: string;
erledigt?: boolean;
wert?: string | null;
kommentar?: string | null;
}): Promise<ActionResult> {
return callRpc("set_onboarding_task", payload, [`/employees/${payload.employee_id}`]);
}
/** Legt die Checkliste nachträglich an — für Personen von vor dieser Liste. */
export async function startOnboarding(employeeId: string): Promise<ActionResult> {
return callRpc(
"start_onboarding",
{ employee_id: employeeId, item_keys: ONBOARDING_PUNKTE.map((x) => x.key) },
[`/employees/${employeeId}`]
);
}
export async function addEmployeeDependent(payload: {
@@ -133,6 +348,25 @@ export async function addEmployeeDependent(payload: {
return callRpc("add_employee_dependent", payload, [`/employees/${payload.employee_id}`]);
}
/**
* Eine Angabe berichtigen — ohne Stichtag.
*
* Hinzufügen und Entfernen tragen einen: dort passiert etwas zu einem
* Zeitpunkt. Eine Berichtigung nicht — der Wert war schon vorher falsch, und
* ein „wirksam ab" hiesse, die Person habe bis dahin anders geheissen.
*/
export async function updateEmployeeDependent(payload: {
dependent_id: string;
employee_id: string;
first_name: string;
last_name: string;
relationship: RelationshipType;
sv_nummer?: string;
birth_date: string;
}): Promise<ActionResult> {
return callRpc("update_employee_dependent", payload, [`/employees/${payload.employee_id}`]);
}
export async function deleteEmployeeDependent(payload: {
dependent_id: string;
employee_id: string;
@@ -141,6 +375,41 @@ export async function deleteEmployeeDependent(payload: {
return callRpc("delete_employee_dependent", payload, [`/employees/${payload.employee_id}`]);
}
/**
* Nimmt eine irrtümlich erfasste Stammdaten- oder Vertragsänderung zurück.
*
* Was zurückgesetzt wird und was stehen bleibt, entscheidet die Datenbank —
* sie prüft dabei erneut, ob der Eintrag überhaupt gelöscht werden darf. Die
* Oberfläche zeigt den Knopf nur dort, wo es geht (siehe lib/history.ts);
* kommt trotzdem eine Ablehnung zurück, wird deren Begründung angezeigt.
*/
export async function deleteHistoryEntry(payload: {
history_id: string;
employee_id: string;
}): Promise<ActionResult> {
return callRpc("delete_history_entry", { history_id: payload.history_id }, [`/employees/${payload.employee_id}`, "/audit"]);
}
/**
* Berichtigt Wert und/oder Datum eines Historieneintrags.
*
* Geändert wird nur das „Nachher" — was vor der Änderung galt, ist nicht
* nachträglich beschliessbar. Welcher Wert danach in den Stammdaten steht,
* leitet die Datenbank je Feld aus dem jüngsten Eintrag ab, der es trägt.
*/
export async function updateHistoryEntry(payload: {
history_id: string;
employee_id: string;
event_date?: string;
werte: { feld: string; nachher: string | null }[];
}): Promise<ActionResult> {
return callRpc(
"update_history_entry",
{ history_id: payload.history_id, event_date: payload.event_date, werte: payload.werte },
[`/employees/${payload.employee_id}`, "/audit"]
);
}
export async function addEmployeeNote(payload: {
employee_id: string;
category: NoteCategory;
@@ -153,23 +422,3 @@ export async function addEmployeeNote(payload: {
export async function completeEmployeeNote(payload: { note_id: string; employee_id: string }): Promise<ActionResult> {
return callRpc("complete_employee_note", payload, [`/employees/${payload.employee_id}`, "/"]);
}
export type EmployeeSearchResult = { id: string; first_name: string; last_name: string; job_title: string; team_id: string | null };
// Shared by "Position besetzen" (staff an open position) and the reorg
// workbench's "Mitarbeiter:in(nen)" multi-select — both search active/
// on-leave employees by name or title.
export async function searchActiveEmployees(query: string): Promise<EmployeeSearchResult[]> {
const supabase = await createClient();
let q = supabase
.from("employees")
.select("id, first_name, last_name, job_title, team_id")
.in("status", ["Aktiv", "Karenz"])
.limit(20);
if (query.trim()) {
const term = sanitizeIlikeTerm(query.trim());
q = q.or(`first_name.ilike.%${term}%,last_name.ilike.%${term}%,job_title.ilike.%${term}%`);
}
const { data } = await q;
return data ?? [];
}

View File

@@ -1,45 +1,139 @@
"use server";
import { revalidatePath } from "next/cache";
import { createClient } from "@/lib/supabase/server";
import { currentUserId, requireUserId } from "@/lib/auth/session";
import { withUser } from "@/lib/db";
import type { ActionResult } from "@/lib/db/rpc";
type ActionResult = { success: boolean; error?: string };
/**
* Den Entwurf für mich belegen — beim Öffnen und danach im Takt.
*
* Die Regel hire_drafts_update lässt die Zeile nur durch, wenn die Sperre
* frei, meine oder abgelaufen ist. Trifft das Schreiben keine Zeile, hat sie
* jemand anderes offen; das ist kein Fehler, sondern die Auskunft.
*
* Dieselbe Funktion frischt die Sperre auf: sie schreibt locked_at neu,
* solange sie mir gehört. Der Assistent ruft sie darum im Takt, sonst liefe
* die Frist einem langen Ausfüllen davon.
*
* updated_at bleibt unberührt. Eine Sperre ist keine Änderung am Entwurf —
* bewegte sie den Zeitstempel, sortierte sich die Liste um und „Gespeichert
* am" logge.
*/
export async function entwurfSperren(id: string): Promise<ActionResult> {
const userId = await requireUserId();
try {
const ergebnis = await withUser(userId, (tx) =>
tx
.updateTable("hire_drafts")
.set({ locked_by: userId, locked_at: new Date().toISOString() })
.where("id", "=", id)
.executeTakeFirst()
);
if (ergebnis.numUpdatedRows === 0n) {
return { success: false, error: "Dieser Entwurf wird gerade von jemand anderem bearbeitet." };
}
} catch (err) {
return { success: false, error: err instanceof Error ? err.message : "Unbekannter Fehler." };
}
revalidatePath("/");
return { success: true };
}
/**
* Die Sperre zurückgeben.
*
* Die Bedingung auf locked_by steht hier und nicht nur in der Regel: die
* Regel liesse auch das Freigeben einer *abgelaufenen fremden* Sperre zu,
* und das wäre ein stiller Griff in die Arbeit von jemandem, der gerade
* wieder aufgefrischt hat.
*
* Ein Scheitern bleibt ohne Meldung: die Frist räumt die Sperre ohnehin ab,
* und es gäbe nichts, was die Person daraufhin tun könnte.
*/
export async function entwurfFreigeben(id: string): Promise<ActionResult> {
const userId = await requireUserId();
try {
await withUser(userId, (tx) =>
tx
.updateTable("hire_drafts")
.set({ locked_by: null, locked_at: null })
.where("id", "=", id)
.where("locked_by", "=", userId)
.execute()
);
} catch (err) {
return { success: false, error: err instanceof Error ? err.message : "Unbekannter Fehler." };
}
revalidatePath("/");
return { success: true };
}
export async function saveHireDraft(payload: {
id?: string;
step: number;
data: Record<string, unknown>;
}): Promise<ActionResult & { id?: string }> {
const supabase = await createClient();
const {
data: { user },
} = await supabase.auth.getUser();
if (!user) return { success: false, error: "Nicht angemeldet." };
const userId = await currentUserId();
if (!userId) return { success: false, error: "Nicht angemeldet." };
try {
const id = await withUser(userId, async (tx) => {
if (payload.id) {
// Wer schreiben darf, entscheidet die Regel hire_drafts_update:
// der Entwurf muss meiner oder von einer hinzugewählten Person sein,
// **und** die Sperre muss mir gehören.
//
// Die Zahl der geänderten Zeilen wird trotzdem gelesen: eine Regel
// weist ein UPDATE nicht mit einem Fehler ab, sie lässt es ins Leere
// laufen. Ohne diese Prüfung meldete die Anwendung „gespeichert", und
// gespeichert wäre nichts — der ärgerlichste Fall überhaupt, weil die
// Person den Assistenten daraufhin beruhigt zumacht.
const ergebnis = await tx
.updateTable("hire_drafts")
.set({ step: payload.step, payload: payload.data, updated_at: new Date().toISOString() })
.where("id", "=", payload.id)
.executeTakeFirst();
if (ergebnis.numUpdatedRows === 0n) {
throw new Error(
"Der Entwurf liess sich nicht speichern: er wird gerade von jemand anderem bearbeitet oder wurde inzwischen gelöscht."
);
}
return payload.id;
}
const row = await tx
.insertInto("hire_drafts")
.values({ created_by: userId, step: payload.step, payload: payload.data })
.returning("id")
.executeTakeFirstOrThrow();
return row.id;
});
if (payload.id) {
const { error } = await supabase
.from("hire_drafts")
.update({ step: payload.step, payload: payload.data, updated_at: new Date().toISOString() })
.eq("id", payload.id);
if (error) return { success: false, error: error.message };
revalidatePath("/");
return { success: true, id: payload.id };
return { success: true, id };
} catch (err) {
return { success: false, error: err instanceof Error ? err.message : "Unbekannter Fehler." };
}
const { data, error } = await supabase
.from("hire_drafts")
.insert({ created_by: user.id, step: payload.step, payload: payload.data })
.select("id")
.single();
if (error) return { success: false, error: error.message };
revalidatePath("/");
return { success: true, id: data.id };
}
export async function deleteHireDraft(id: string): Promise<ActionResult> {
const supabase = await createClient();
const { error } = await supabase.from("hire_drafts").delete().eq("id", id);
if (error) return { success: false, error: error.message };
revalidatePath("/");
return { success: true };
try {
// Auch hier die Zeilenzahl: die Regel hire_drafts_delete lässt ein
// Löschen gegen eine fremde Sperre leer laufen statt es abzuweisen.
// „Entwurf gelöscht" über einem Entwurf, der noch dasteht, wäre die
// schlechtere Auskunft.
await withUser(await currentUserId(), async (tx) => {
const ergebnis = await tx.deleteFrom("hire_drafts").where("id", "=", id).executeTakeFirst();
if (ergebnis.numDeletedRows === 0n) {
throw new Error(
"Der Entwurf liess sich nicht löschen: er wird gerade von jemand anderem bearbeitet oder war schon weg."
);
}
});
revalidatePath("/");
return { success: true };
} catch (err) {
return { success: false, error: err instanceof Error ? err.message : "Unbekannter Fehler." };
}
}

66
actions/notes.ts Normal file
View File

@@ -0,0 +1,66 @@
"use server";
import { revalidatePath } from "next/cache";
import { requireUserId } from "@/lib/auth/session";
import { withUser } from "@/lib/db";
import type { ActionResult } from "@/lib/db/rpc";
/**
* Eine Kollegin oder einen Kollegen hinzuwählen oder abwählen.
*
* Die Auswahl steuert zwei Listen: die Notizen in der Glocke und die
* Entwürfe auf der Übersicht. Der Name der Funktion nennt nur die erste,
* weil die Einstellung in der Glocke sitzt — was sie bewirkt, steht an der
* Einstellung selbst.
*
* Kein Aufruf einer SQL-Funktion und kein Protokolleintrag, anders als bei
* allem, was Personaldaten ändert: das hier ist eine persönliche
* Anzeigeeinstellung. Ein Prüfprotokoll, das jeden Haken mitschreibt, machte
* die Suche nach echten Änderungen mühsamer, ohne etwas nachzuweisen.
* Dasselbe Muster wie bei gespeicherten Auswertungen und Entwürfen
* (actions/reports.ts, actions/hireDrafts.ts).
*
* Abgesichert ist es trotzdem: die Regel `colleague_subscriptions_owner` lässt nur Zeilen
* zu, deren `user_id` die angemeldete Person ist. Eine fremde Einstellung
* liesse sich auch mit erfundenen Werten nicht schreiben.
*/
export async function setNotizSichtbarkeit(payload: {
kollegeId: string;
sichtbar: boolean;
}): Promise<ActionResult> {
const userId = await requireUserId();
// Die eigenen Notizen sind ohnehin immer dabei. Die Prüfbedingung der
// Tabelle weist das ab; hier kommt die Meldung heraus, die jemand lesen
// kann, statt einer Verletzungsmeldung aus der Datenbank.
if (payload.kollegeId === userId) {
return { success: false, error: "Die eigenen Notizen sind immer dabei." };
}
try {
await withUser(userId, async (tx) => {
if (payload.sichtbar) {
// `on conflict do nothing`: zweimal dasselbe Hinzuwählen ist kein
// Fehler, sondern derselbe Wunsch — etwa wenn zwei Reiter offen sind.
await tx
.insertInto("colleague_subscriptions")
.values({ user_id: userId, author_user_id: payload.kollegeId })
.onConflict((oc) => oc.columns(["user_id", "author_user_id"]).doNothing())
.execute();
} else {
await tx
.deleteFrom("colleague_subscriptions")
.where("user_id", "=", userId)
.where("author_user_id", "=", payload.kollegeId)
.execute();
}
});
} catch (err) {
return { success: false, error: err instanceof Error ? err.message : "Unbekannter Fehler." };
}
// Die Glocke steckt in der Hülle jeder Seite, die Karte „Anstehend" auf der
// Übersicht. Beide zeigen dieselbe Menge und müssen gemeinsam nachziehen.
revalidatePath("/", "layout");
return { success: true };
}

47
actions/org.ts Normal file
View File

@@ -0,0 +1,47 @@
"use server";
import { revalidatePath } from "next/cache";
import { currentUserId } from "@/lib/auth/session";
import { runMutation, type ActionResult } from "@/lib/db/rpc";
/**
* Eine Organisationseinheit unter einer bestehenden anlegen.
*
* Bewusst die einzige Änderung an der Struktur, die es aus der Anwendung
* heraus gibt. Umbenennen, verschieben und schliessen fehlen nicht aus
* Zeitmangel: org_units.parent_id trägt kein Datum, ein Verschieben änderte
* damit auch jede Auswertung auf einen vergangenen Stichtag. Siehe Migration
* 20260929120000.
*/
const ORG_PFADE = ["/orgchart", "/positions", "/"];
export async function createOrgUnit(payload: {
parent_id: string;
org_number: string;
name: string;
unit_type: "Bereich" | "Abteilung" | "Team";
valid_from: string;
/** Leer lassen heisst: die Einheit entsteht ohne Leitung. */
leitung_taetigkeit?: string;
}): Promise<ActionResult> {
const result = await runMutation(await currentUserId(), "create_org_unit", payload);
if (!result.success) return result;
// Die Einheit taucht in drei Ansichten auf, und in allen dreien wäre sie
// sonst erst nach dem nächsten harten Neuladen zu sehen.
for (const path of ORG_PFADE) revalidatePath(path);
return result;
}
/**
* Eine Organisationseinheit entfernen.
*
* Geht nur, solange nichts darunter hängt und nie etwas hing. Alles andere
* weist die Datenbankfunktion mit dem Grund ab — ein Schliessen zum Stichtag
* gibt es nicht, weil org_units nirgends gegen den Stichtag gelesen wird.
*/
export async function deleteOrgUnit(orgUnitId: string): Promise<ActionResult> {
const result = await runMutation(await currentUserId(), "delete_org_unit", { org_unit_id: orgUnitId });
if (!result.success) return result;
for (const path of ORG_PFADE) revalidatePath(path);
return result;
}

61
actions/passwort.ts Normal file
View File

@@ -0,0 +1,61 @@
"use server";
import { redirect } from "next/navigation";
import { currentUserId } from "@/lib/auth/session";
import { runMutation } from "@/lib/db/rpc";
// Das eigene Passwort wechseln.
//
// Getrennt von actions/auth.ts, weil es etwas anderes ist: dort geht es um das
// Herstellen einer Sitzung, hier um eine Änderung an den eigenen Daten. Und
// getrennt von actions/benutzer.ts (Benutzerverwaltung), weil diese Aktion die
// einzige ist, die **ohne** HR-Rechte funktionieren muss.
export type WechselZustand = { fehler: string | null };
/**
* Wechselt das Passwort der angemeldeten Person.
*
* Kein `revalidatePath`: der Weg danach ist eine Weiterleitung durch die
* Komponente, und es gibt keine zwischengespeicherte Seite, die den alten Stand
* zeigen könnte.
*
* Die Meldungen kommen aus app_passwort_aendern() und sind für die Oberfläche
* geschrieben („Das bisherige Passwort stimmt nicht.") — sie werden
* durchgereicht wie bei jeder anderen Mutation.
*/
export async function passwortAendern(
_zustand: WechselZustand,
formular: FormData
): Promise<WechselZustand> {
const altes = String(formular.get("altes_passwort") ?? "");
const neues = String(formular.get("neues_passwort") ?? "");
const wiederholung = String(formular.get("wiederholung") ?? "");
if (!altes || !neues) {
return { fehler: "Bitte das bisherige und das neue Passwort eingeben." };
}
// Diese eine Prüfung gehört hierher und nicht in die Datenbank: die
// Wiederholung ist ein Bedienelement gegen Vertippen, kein Datum. Die
// Datenbank sieht sie nie und soll sie auch nicht sehen.
if (neues !== wiederholung) {
return { fehler: "Die beiden neuen Passwörter stimmen nicht überein." };
}
const ergebnis = await runMutation(await currentUserId(), "app_passwort_aendern", {
altes_passwort: altes,
neues_passwort: neues,
});
if (!ergebnis.success) {
return { fehler: ergebnis.error ?? "Unbekannter Fehler." };
}
// Ab hier ist der Wechsel erledigt, is_hr_user() liefert wieder true und die
// Anwendung ist offen. Die Weiterleitung steht in der Aktion und nicht in der
// Komponente: `redirect()` wirft, die Aktion kehrt also nicht zurück, und es
// gibt keinen Zwischenzustand, in dem das Formular noch einmal abgeschickt
// werden könnte.
redirect("/");
}

View File

@@ -1,56 +1,174 @@
"use server";
import { revalidatePath } from "next/cache";
import { sanitizeIlikeTerm } from "@/lib/supabase/query";
import { createClient } from "@/lib/supabase/server";
type ActionResult = { success: boolean; error?: string };
import { currentUserId } from "@/lib/auth/session";
import { kontierungZum, kostenstellenAbfrage, type KontierungsZeile } from "@/lib/cost-centers";
import { withUser } from "@/lib/db";
import { jsonArrayFrom } from "@/lib/db/json";
import { runMutation, type ActionResult } from "@/lib/db/rpc";
import { fmtName, todayIso } from "@/lib/format";
import type { PlanstelleZumAendern } from "@/lib/positions";
const POSITION_PATHS = ["/positions", "/orgchart", "/"];
async function callRpc(
fn: "create_position" | "delete_position",
fn: "create_position" | "clone_position" | "update_position" | "delete_position" | "set_position_cost_center",
payload: Record<string, unknown>,
revalidate: string[]
): Promise<ActionResult> {
const supabase = await createClient();
const { error } = await supabase.rpc(fn, { payload });
if (error) return { success: false, error: error.message };
const result = await runMutation(await currentUserId(), fn, payload);
if (!result.success) return result;
for (const path of revalidate) revalidatePath(path);
return { success: true };
return result;
}
export async function createPosition(payload: {
title: string;
superior_employee_id: string;
is_lead: boolean;
team_id?: string;
org_unit_id: string;
job_title: string;
is_chief: boolean;
valid_from: string;
}): Promise<ActionResult> {
return callRpc("create_position", payload, POSITION_PATHS);
}
/**
* Eine Planstelle als Kopie einer bestehenden anlegen.
*
* Kein eigenes Formular: Einheit, Tätigkeit und Kontierung kommen von der
* Vorlage, getippt wird nichts. Genau das ist der Zweck — zwölf gleiche
* Planstellen von Hand anzulegen erzeugt zwölf Gelegenheiten, die Tätigkeit
* unterschiedlich zu schreiben, und ab der zweiten Schreibweise ist jede
* Auswertung nach Tätigkeit falsch.
*
* Dass Leitungsplanstellen ausgenommen sind, entscheidet die SQL-Funktion und
* nicht diese Stelle. Die Oberfläche blendet den Knopf dort aus, aber das ist
* eine Bequemlichkeit, keine Regel.
*/
export async function clonePosition(payload: { position_id: string; valid_from?: string }): Promise<ActionResult> {
return callRpc("clone_position", payload, POSITION_PATHS);
}
/**
* Ändert eine Planstelle.
*
* Weggelassene Felder bleiben, wie sie sind. `valid_to: null` beendet die
* Befristung ausdrücklich — deshalb ist es hier `string | null` und nicht
* optional: „nicht mitgeschickt" und „auf leer setzen" müssen unterscheidbar
* bleiben.
*/
export async function updatePosition(payload: {
position_id: string;
org_unit_id?: string;
job_title?: string;
is_chief?: boolean;
valid_from?: string;
valid_to?: string | null;
}): Promise<ActionResult> {
return callRpc("update_position", payload, POSITION_PATHS);
}
export async function deletePosition(positionId: string): Promise<ActionResult> {
return callRpc("delete_position", { position_id: positionId }, POSITION_PATHS);
}
export type SuperiorSearchResult = { id: string; first_name: string; last_name: string; job_title: string; division_id: string };
// For "Position ausschreiben": superior lookup, filtered to team-leads when
// the new position is an IC role, or to division-heads/CEO when the new
// position is itself a team lead (§2).
export async function searchSuperiors(query: string, forLeadPosition: boolean): Promise<SuperiorSearchResult[]> {
const supabase = await createClient();
let q = supabase
.from("employees")
.select("id, first_name, last_name, job_title, division_id")
.eq("status", "Aktiv")
.limit(20);
q = forLeadPosition ? q.lte("org_level", 1) : q.eq("is_lead", true).eq("org_level", 2);
if (query.trim()) {
const term = sanitizeIlikeTerm(query.trim());
q = q.or(`first_name.ilike.%${term}%,last_name.ilike.%${term}%,job_title.ilike.%${term}%`);
}
const { data } = await q;
return data ?? [];
/**
* Kontiert eine Planstelle auf eine andere Kostenstelle — zum Stichtag.
*
* Kein Feld im Änderungsdialog, sondern ein eigener Vorgang, weil es einer
* ist: die laufende Kontierung wird beendet, die neue beginnt. Die alte
* einfach zu überschreiben hiesse, die Kosten der Vergangenheit nachträglich
* anderswohin zu buchen.
*/
export async function setPositionCostCenter(payload: {
position_id: string;
cost_center_id: string;
valid_from: string;
}): Promise<ActionResult> {
return callRpc("set_position_cost_center", payload, POSITION_PATHS);
}
export type PlanstelleDerEinheit = PlanstelleZumAendern & {
/** Wer am Stichtag darauf sitzt; null heisst unbesetzt. */
besetztVon: string | null;
};
/**
* Die Planstellen einer Organisationseinheit — **auch die besetzten**.
*
* Gelesen, nicht geschrieben, und erst beim Öffnen der Einheit: der Bestand
* zählt 788 Planstellen, und sie alle in jede Zeichnung des Organigramms zu
* legen hiesse, für achtzig Einheiten zu laden, was man für eine braucht.
*
* Der Grund, warum es diese Abfrage überhaupt gibt: die Seite Positionen zeigt
* nur unbesetzte Stellen, und der Änderungsdialog war allein von dort aus
* erreichbar. Die Kontierung einer besetzten Planstelle liess sich damit
* nirgends ändern.
*
* Kein Schutzgatter im Anwendungscode: die Zeilenschutz-Regeln geben einer
* Person ohne HR-Recht nichts zurück, und das ist die Grenze, die zählt.
*/
export async function ladePlanstellenDerEinheit(orgUnitId: string): Promise<{
planstellen: PlanstelleDerEinheit[];
kostenstellen: { id: string; code: string; name: string }[];
/** Vom Server: der Dialog rechnet sonst mit der Zone des Browsers. */
heute: string;
}> {
const heute = todayIso();
const g = await withUser(await currentUserId(), (tx) =>
tx
.selectNoFrom((eb) => [
jsonArrayFrom(
eb
.selectFrom("om_positions as p")
.innerJoin("jobs as j", "j.id", "p.job_id")
.select(["p.id", "p.position_number", "p.org_unit_id", "p.is_chief", "p.valid_from", "p.valid_to", "j.title"])
.where("p.org_unit_id", "=", orgUnitId)
.orderBy("p.position_number")
).as("stellen"),
jsonArrayFrom(
eb
.selectFrom("position_assignments as a")
.innerJoin("om_positions as p", "p.id", "a.position_id")
.innerJoin("employees as e", "e.id", "a.employee_id")
.select(["a.position_id", "e.first_name", "e.last_name"])
.where("p.org_unit_id", "=", orgUnitId)
.where((x) => x.or([x("a.valid_to", "is", null), x("a.valid_to", ">", heute)]))
).as("besetzungen"),
// Nicht kontierungenAbfrage(): die filtert über eine Liste von
// Planstellen, die hier erst aus der ersten Teilabfrage käme — und das
// wäre eine zweite Rundreise für dieselbe Auskunft.
jsonArrayFrom(
eb
.selectFrom("position_cost_centers as z")
.innerJoin("cost_centers as k", "k.id", "z.cost_center_id")
.innerJoin("om_positions as p", "p.id", "z.position_id")
.select(["z.position_id", "z.cost_center_id", "k.code", "k.name", "z.valid_from", "z.valid_to"])
.where("p.org_unit_id", "=", orgUnitId)
.orderBy("z.valid_from")
).as("kontierungen"),
jsonArrayFrom(kostenstellenAbfrage(eb, heute)).as("kostenstellen"),
])
.executeTakeFirstOrThrow()
);
const kontierung = kontierungZum(g.kontierungen as KontierungsZeile[], heute);
const inhaber = new Map(g.besetzungen.map((b) => [b.position_id, fmtName(b.first_name, b.last_name)]));
return {
planstellen: g.stellen.map((p) => ({
id: p.id,
position_number: p.position_number,
title: p.title,
org_unit_id: p.org_unit_id,
is_chief: p.is_chief,
valid_from: p.valid_from,
valid_to: p.valid_to,
kostenstelle: kontierung.get(p.id) ?? null,
besetztVon: inhaber.get(p.id) ?? null,
})),
kostenstellen: g.kostenstellen,
heute,
};
}

View File

@@ -1,37 +0,0 @@
"use server";
import { revalidatePath } from "next/cache";
import { createClient } from "@/lib/supabase/server";
type ActionResult = { success: boolean; error?: string };
export type ReorgMovePayload = {
kind: "emp" | "team" | "abt" | "dept";
label: string;
employee_ids: string[];
target_team_id: string;
};
export async function applyReorg(payload: {
name: string;
effective_date: string;
moves: ReorgMovePayload[];
}): Promise<ActionResult & { scenarioId?: string }> {
const supabase = await createClient();
const { data, error } = await supabase.rpc("apply_reorg", { payload });
if (error) return { success: false, error: error.message };
revalidatePath("/orgchart");
revalidatePath("/employees");
revalidatePath("/");
return { success: true, scenarioId: data as string };
}
export async function undoReorg(payload: { scenario_id: string }): Promise<ActionResult> {
const supabase = await createClient();
const { error } = await supabase.rpc("undo_reorg", { payload });
if (error) return { success: false, error: error.message };
revalidatePath("/orgchart");
revalidatePath("/employees");
revalidatePath("/");
return { success: true };
}

View File

@@ -1,27 +1,31 @@
"use server";
import { revalidatePath } from "next/cache";
import { createClient } from "@/lib/supabase/server";
type ActionResult = { success: boolean; error?: string };
import { currentUserId } from "@/lib/auth/session";
import { withUser } from "@/lib/db";
import type { ActionResult } from "@/lib/db/rpc";
export async function saveReport(payload: { name: string; config: Record<string, unknown> }): Promise<ActionResult> {
const supabase = await createClient();
const {
data: { user },
} = await supabase.auth.getUser();
if (!user) return { success: false, error: "Nicht angemeldet." };
const userId = await currentUserId();
if (!userId) return { success: false, error: "Nicht angemeldet." };
const { error } = await supabase.from("saved_reports").insert({ created_by: user.id, name: payload.name, config: payload.config });
if (error) return { success: false, error: error.message };
revalidatePath("/reports");
return { success: true };
try {
await withUser(userId, (tx) =>
tx.insertInto("saved_reports").values({ created_by: userId, name: payload.name, config: payload.config }).execute()
);
revalidatePath("/reports");
return { success: true };
} catch (err) {
return { success: false, error: err instanceof Error ? err.message : "Unbekannter Fehler." };
}
}
export async function deleteReport(id: string): Promise<ActionResult> {
const supabase = await createClient();
const { error } = await supabase.from("saved_reports").delete().eq("id", id);
if (error) return { success: false, error: error.message };
revalidatePath("/reports");
return { success: true };
try {
await withUser(await currentUserId(), (tx) => tx.deleteFrom("saved_reports").where("id", "=", id).execute());
revalidatePath("/reports");
return { success: true };
} catch (err) {
return { success: false, error: err instanceof Error ? err.message : "Unbekannter Fehler." };
}
}

View File

@@ -1,11 +1,12 @@
import Link from "next/link";
import { Suspense } from "react";
import { AuditDetail } from "@/components/audit/AuditDetail";
import { AuditFilters } from "@/components/audit/AuditFilters";
import { CARD_CLASS } from "@/components/ui/Card";
import { Pagination } from "@/components/ui/Pagination";
import { actionBadgeStyle } from "@/lib/colors";
import { sanitizeIlikeTerm } from "@/lib/supabase/query";
import { createClient } from "@/lib/supabase/server";
import { currentUserId } from "@/lib/auth/session";
import { withUser } from "@/lib/db";
const PAGE_SIZE = 25;
@@ -20,8 +21,8 @@ function pageHref(params: SearchParams, page: number): string {
}
// Pinned to Vienna and built once: audit_log.occurred_at is a timestamptz, and
// an unpinned formatter renders it in the *server's* zone — UTC in Docker and
// on Vercel — so every entry would read an hour or two early for the people
// an unpinned formatter renders it in the *server's* zone — UTC in the
// container — so every entry would read an hour or two early for the people
// the log is for.
const dateTimeFormatter = new Intl.DateTimeFormat("de-AT", {
day: "2-digit",
@@ -34,35 +35,58 @@ const dateTimeFormatter = new Intl.DateTimeFormat("de-AT", {
export default async function AuditPage({ searchParams }: { searchParams: Promise<SearchParams> }) {
const params = await searchParams;
const supabase = await createClient();
const page = Math.max(1, Number(params.page ?? "1") || 1);
const from = (page - 1) * PAGE_SIZE;
const to = from + PAGE_SIZE - 1;
let query = supabase
.from("audit_log")
.select("id, occurred_at, actor_name, action, target_label, target_employee_id, details", { count: "exact" })
.order("occurred_at", { ascending: false })
.range(from, to);
const { entries, count } = await withUser(await currentUserId(), async (tx) => {
const base = () => {
let q = tx.selectFrom("audit_log");
if (params.action) q = q.where("action", "=", params.action);
if (params.q) {
// Als Parameter gebunden statt in die Abfrage geschrieben: die
// Zeichen, die in der alten Filtersyntax ausbrechen konnten, haben
// hier keine Bedeutung mehr.
const like = `%${params.q.trim()}%`;
q = q.where((eb) =>
eb.or([eb("target_label", "ilike", like), eb("details", "ilike", like), eb("actor_name", "ilike", like)])
);
}
return q;
};
if (params.action) query = query.eq("action", params.action);
if (params.q) {
const q = sanitizeIlikeTerm(params.q.trim());
query = query.or(`target_label.ilike.%${q}%,details.ilike.%${q}%,actor_name.ilike.%${q}%`);
}
const [entries, total] = await Promise.all([
base()
.select(["id", "occurred_at", "actor_name", "action", "target_label", "target_employee_id", "details", "changes"])
// Nach id als zweitem Kriterium: bei gleichem Zeitstempel wäre die
// Reihenfolge sonst unbestimmt und ein Eintrag könnte auf zwei Seiten
// erscheinen oder auf keiner.
.orderBy("occurred_at", "desc")
.orderBy("id", "desc")
.limit(PAGE_SIZE)
.offset((page - 1) * PAGE_SIZE)
.execute(),
base()
.select(({ fn }) => fn.countAll<string>().as("anzahl"))
.executeTakeFirst(),
]);
return { entries, count: Number(total?.anzahl ?? 0) };
});
const { data: entries, count } = await query;
const totalPages = Math.max(1, Math.ceil((count ?? 0) / PAGE_SIZE));
const totalPages = Math.max(1, Math.ceil(count / PAGE_SIZE));
return (
<div className="flex flex-col gap-4">
<Suspense>
<AuditFilters />
</Suspense>
<p className="text-sm text-ink-muted">{count ?? 0} Einträge</p>
<p className="text-sm text-ink-muted">{count} Einträge</p>
<div className={`overflow-x-auto ${CARD_CLASS}`}>
{/* `overflow-y-hidden` gehört zwingend dazu und ist keine Vorsicht:
nach CSS wird eine auf `visible` stehende Achse auf `auto`
hochgestuft, sobald die andere nicht `visible` ist. `overflow-x-auto`
allein macht aus der Karte also einen Scrollbereich in **beiden**
Richtungen — mit einer senkrechten Leiste, die niemand bestellt hat.
Geklemmt wird dabei nichts: die Karte ist so hoch wie ihr Inhalt. */}
<div className={`overflow-x-auto overflow-y-hidden ${CARD_CLASS}`}>
<table className="w-full min-w-[800px] text-sm">
<thead>
<tr className="border-b border-border bg-surface text-left text-[11px] font-bold uppercase tracking-wider text-ink-muted">
@@ -74,7 +98,7 @@ export default async function AuditPage({ searchParams }: { searchParams: Promis
</tr>
</thead>
<tbody>
{(entries ?? []).map((entry) => {
{entries.map((entry) => {
return (
<tr key={entry.id} className="border-b border-border-subtle transition-colors last:border-0 hover:bg-brand-50">
<td className="whitespace-nowrap px-4 py-2.5 tabular-nums text-ink-body">
@@ -98,11 +122,13 @@ export default async function AuditPage({ searchParams }: { searchParams: Promis
entry.target_label
)}
</td>
<td className="px-4 py-2.5 text-ink-muted">{entry.details ?? "–"}</td>
<td className="px-2 py-1.5">
<AuditDetail eintrag={entry} />
</td>
</tr>
);
})}
{(entries ?? []).length === 0 && (
{entries.length === 0 && (
<tr>
<td colSpan={5} className="px-4 py-8 text-center text-sm text-ink-muted">
Keine Einträge gefunden.

View File

@@ -0,0 +1,54 @@
import { notFound } from "next/navigation";
import { PrintChecklist } from "@/components/employees/PrintChecklist";
import { currentUserId } from "@/lib/auth/session";
import { artTitel, checklistDateiname, parseArt } from "@/lib/checklist-print";
import { loadChecklistPrint } from "@/lib/checklist-print-data";
import { withUser } from "@/lib/db";
import { todayIso } from "@/lib/format";
import { OFFBOARDING_GRUPPEN } from "@/lib/offboarding";
import { ONBOARDING_GRUPPEN } from "@/lib/onboarding";
// Eigene Route statt eines Druckstils auf dem Reiter.
//
// Der Reiter ist zum Arbeiten gebaut: Haken zum Anklicken, Eingabefelder,
// Kommentarknöpfe. Auf Papier ist davon nichts nützlich. Hier entsteht aus
// denselben Daten ein Blatt, das den Stand festhält — mit Kopf, Fortschritt
// und Platz für zwei Unterschriften.
type Props = {
params: Promise<{ id: string }>;
searchParams: Promise<{ art?: string }>;
};
/**
* Der Titel ist zugleich der Dateivorschlag im Druckdialog. Er wird hier
* gesetzt *und* in der Komponente noch einmal — hier für den Tab und den Fall,
* dass jemand die Seite direkt druckt, dort, weil der Titel aus den geladenen
* Daten kommt und die Metadaten sonst ein zweites Mal laden müssten.
*/
export async function generateMetadata({ params, searchParams }: Props) {
const [{ id }, sp] = await Promise.all([params, searchParams]);
const art = parseArt(sp.art);
const daten = await withUser(await currentUserId(), (tx) => loadChecklistPrint(tx, id, art));
if (!daten) return { title: artTitel(art) };
return { title: checklistDateiname(art, daten.kopf, todayIso()) };
}
export default async function ChecklistPrintPage({ params, searchParams }: Props) {
const [{ id }, sp] = await Promise.all([params, searchParams]);
const art = parseArt(sp.art);
const today = todayIso();
const daten = await withUser(await currentUserId(), (tx) => loadChecklistPrint(tx, id, art, today));
if (!daten) notFound();
return (
<PrintChecklist
art={art}
kopf={daten.kopf}
gruppen={art === "offboarding" ? OFFBOARDING_GRUPPEN : ONBOARDING_GRUPPEN}
staende={daten.staende}
today={today}
/>
);
}

View File

@@ -1,74 +1,57 @@
import { notFound } from "next/navigation";
import { EmployeeDetail } from "@/components/employees/EmployeeDetail";
import { createClient } from "@/lib/supabase/server";
import type { Database } from "@/lib/supabase/types";
import { currentUserId } from "@/lib/auth/session";
import { withUser } from "@/lib/db";
import { todayIso } from "@/lib/format";
import { breadcrumbLabel } from "@/lib/org";
import { loadEmployeeDetail } from "@/lib/employee-detail-data";
type PageProps = { params: Promise<{ id: string }> };
type EmployeeWithManager = Database["public"]["Tables"]["employees"]["Row"] & {
manager: { id: string; first_name: string; last_name: string; job_title: string } | null;
};
export default async function EmployeeDetailPage({ params }: PageProps) {
const { id } = await params;
const supabase = await createClient();
const today = todayIso();
// Everything here keys off the id already in the URL, and the manager
// comes back as an embedded resource on the employee row rather than as a
// follow-up query — so the page is one round trip instead of two. Measured
// against the hosted database that halved the data time (120ms -> 62ms,
// median of five), because a round trip costs more than these queries do.
//
// The hand-written Database type carries no relationship metadata
// (NoRelationships), so the embed is typed at the destructure below.
const [
{ data: employeeRow },
{ data: directReports },
{ data: history },
{ data: dependents },
{ data: notes },
{ data: divisions },
{ data: departments },
{ data: teams },
{ data: locations },
{ data: openPositions },
] = await Promise.all([
supabase.from("employees").select("*, manager:manager_id(id, first_name, last_name, job_title)").eq("id", id).single(),
supabase.from("employees").select("id, first_name, last_name, job_title, status").eq("manager_id", id).order("last_name"),
supabase
.from("employee_history")
.select("*")
.eq("employee_id", id)
.order("event_date", { ascending: false })
.order("created_at", { ascending: false }),
supabase.from("employee_dependents").select("*").eq("employee_id", id).order("created_at"),
supabase.from("employee_notes").select("*").eq("employee_id", id).order("created_at", { ascending: false }),
supabase.from("divisions").select("*").order("name"),
supabase.from("departments").select("*"),
supabase.from("teams").select("*"),
supabase.from("locations").select("*").order("name"),
supabase.from("positions").select("id, position_number, title, team_id, is_lead").eq("status", "open"),
]);
// Was die Akte liest und in wie vielen Rundreisen, steht in
// lib/employee-detail-data.ts.
const data = await withUser(await currentUserId(), (tx) => loadEmployeeDetail(tx, id, today));
if (!employeeRow) notFound();
// Split the embedded manager back off so EmployeeDetail keeps receiving a
// plain employees row plus a separate manager, unchanged.
const { manager, ...employee } = employeeRow as EmployeeWithManager;
if (!data) notFound();
const { employee, line, reports, history, dependents, notes, orgMaps, placement, kostenstelle, onboarding, offboarding, openPositions, byId } = data;
return (
<EmployeeDetail
employee={employee}
manager={manager ?? null}
directReports={directReports ?? []}
placement={
placement && {
positionNumber: placement.positionNumber,
jobTitle: placement.jobTitle,
isChief: placement.isChief,
current: placement.current,
}
}
breadcrumb={breadcrumbLabel(orgMaps, placement?.orgUnitId)}
kostenstelle={kostenstelle}
onboarding={onboarding}
offboarding={offboarding}
manager={(line?.acting_manager_id ? byId.get(line.acting_manager_id) : null) ?? null}
// Nur wenn eine Vertretung im Spiel ist — sonst stünde dieselbe Person
// zweimal da.
formalManager={
line?.formal_manager_id && line.formal_manager_id !== line.acting_manager_id
? (byId.get(line.formal_manager_id) ?? null)
: null
}
directReports={reports.flatMap((r) => {
const e = byId.get(r.employee_id);
return e ? [e] : [];
})}
history={history ?? []}
dependents={dependents ?? []}
notes={notes ?? []}
divisions={divisions ?? []}
departments={departments ?? []}
teams={teams ?? []}
locations={locations ?? []}
openPositions={openPositions ?? []}
locations={orgMaps.locationList}
openPositions={openPositions}
today={today}
/>
);
}

View File

@@ -5,19 +5,74 @@ import { Avatar } from "@/components/ui/Avatar";
import { CARD_CLASS } from "@/components/ui/Card";
import { Pagination } from "@/components/ui/Pagination";
import { StatusChip } from "@/components/ui/StatusChip";
import { applyDerivedStatusFilter } from "@/lib/employee-status-filter";
import { fmtDate, todayIso } from "@/lib/format";
import { breadcrumbFor, loadOrgMaps } from "@/lib/org";
import { sanitizeIlikeTerm } from "@/lib/supabase/query";
import { createClient } from "@/lib/supabase/server";
import type { EmploymentStatus } from "@/lib/supabase/types";
import { currentUserId } from "@/lib/auth/session";
import { sql, withUser } from "@/lib/db";
import { jsonArrayFrom, jsonObjectFrom } from "@/lib/db/json";
import { istPersonalnummer, suchMuster, TRENNZEICHEN, TRENNZEICHEN_ERSATZ } from "@/lib/employee-search";
import {
SORTIERFELDER,
naechsteRichtung,
sortiere,
parseFeld,
parseRichtung,
type Richtung,
type Sortierfeld,
} from "@/lib/employee-sort";
import { derivedStatusFilter } from "@/lib/employee-status-filter";
import { fmtDate, fmtName, todayIso } from "@/lib/format";
import { breadcrumbLabel, loadOrgMaps, subtreeOf, unitOf, type OrgEb } from "@/lib/org";
import { loadPlacements } from "@/lib/placement";
import type { EmploymentStatus } from "@/lib/types";
const PAGE_SIZE = 15;
type SearchParams = { q?: string; division?: string; status?: string; location?: string; page?: string };
/**
* Die Parameter, nachdem sie geglättet sind — je einer, oder keiner.
*
* Was Next tatsächlich liefert, steht in RohParams: derselbe Name zweimal in
* der Adresse wird dort zu einem Array. Diese Seite hat das nicht erwartet
* und ist daran gescheitert — eine Kachel der Übersicht verwies auf
* `?status=Aktiv&status=Karenz`, und `params.status.split(",")` lief gegen
* ein Array. Sichtbar war davon nur „Diese Ansicht konnte nicht geladen
* werden" mit einer Fehlerkennung.
*
* Die Kachel ist berichtigt (sie schreibt jetzt `status=Aktiv,Karenz`), aber
* eine Adresse kommt nicht nur aus der eigenen Anwendung: sie steht in
* Lesezeichen, in Verknüpfungen, in E-Mails. Deshalb wird hier geglättet
* statt sich darauf zu verlassen, dass niemand zweimal denselben Namen
* schreibt.
*/
type SearchParams = {
q?: string;
division?: string;
status?: string;
location?: string;
sort?: string;
dir?: string;
page?: string;
};
type RohParams = Record<string, string | string[] | undefined>;
/** Der erste Wert eines Parameters — auch wenn er mehrfach in der Adresse steht. */
function einWert(wert: string | string[] | undefined): string | undefined {
return Array.isArray(wert) ? wert[0] : wert;
}
function glaetten(roh: RohParams): SearchParams {
return {
q: einWert(roh.q),
division: einWert(roh.division),
status: einWert(roh.status),
location: einWert(roh.location),
sort: einWert(roh.sort),
dir: einWert(roh.dir),
page: einWert(roh.page),
};
}
type EmployeesPageProps = {
searchParams: Promise<SearchParams>;
searchParams: Promise<RohParams>;
};
function pageHref(params: SearchParams, page: number): string {
@@ -26,78 +81,272 @@ function pageHref(params: SearchParams, page: number): string {
if (params.division) sp.set("division", params.division);
if (params.status) sp.set("status", params.status);
if (params.location) sp.set("location", params.location);
// Ohne das kippte die Liste beim Blättern zurück auf den Standard, und
// Seite 2 zeigte Namen, die auf Seite 1 schon standen.
if (params.sort) sp.set("sort", params.sort);
if (params.dir) sp.set("dir", params.dir);
sp.set("page", String(page));
return `/employees?${sp.toString()}`;
}
/**
* Die Adresse hinter einem Spaltenkopf.
*
* Ohne `page`: nach dem Umsortieren steht auf Seite 7 etwas völlig anderes
* als vorher. Wer sortiert, will von vorne anfangen.
*/
function sortHref(params: SearchParams, feld: Sortierfeld, aktuell: Sortierfeld, richtung: Richtung): string {
const sp = new URLSearchParams();
if (params.q) sp.set("q", params.q);
if (params.division) sp.set("division", params.division);
if (params.status) sp.set("status", params.status);
if (params.location) sp.set("location", params.location);
sp.set("sort", feld);
sp.set("dir", naechsteRichtung(aktuell, richtung, feld));
return `/employees?${sp.toString()}`;
}
export default async function EmployeesPage({ searchParams }: EmployeesPageProps) {
const params = await searchParams;
const supabase = await createClient();
const params = glaetten(await searchParams);
const page = Math.max(1, Number(params.page ?? "1") || 1);
const from = (page - 1) * PAGE_SIZE;
const to = from + PAGE_SIZE - 1;
const sortFeld = parseFeld(params.sort);
const sortRichtung = parseRichtung(params.dir);
const today = todayIso();
let query = supabase
.from("employees")
.select(
"id, first_name, last_name, personnel_number, job_title, team_id, division_id, location_id, entry_date, employment_type, weekly_hours, status, absence_type",
{ count: "exact" }
)
.order("last_name", { ascending: true })
.range(from, to);
if (params.q) {
const q = params.q.trim();
if (/^\d+$/.test(q)) {
query = query.eq("personnel_number", Number(q));
} else {
const term = sanitizeIlikeTerm(q);
query = query.or(`first_name.ilike.%${term}%,last_name.ilike.%${term}%,job_title.ilike.%${term}%`);
}
}
if (params.division) query = query.eq("division_id", params.division);
// Comma-separated, so a dashboard tile can link here with the same
// status set it counted rather than a narrower one.
const statuses = (params.status ?? "")
.split(",")
.map((s) => s.trim())
.filter((s): s is EmploymentStatus => (["Aktiv", "Karenz", "Geplant", "Ausgetreten"] as const).includes(s as EmploymentStatus));
// Derived from the dates, not read off employees.status — see
// lib/employee-status-filter.ts for why the two can disagree.
query = applyDerivedStatusFilter(query, statuses, todayIso());
if (params.location) query = query.eq("location_id", params.location);
// The org lookup tables are needed only to label the rows, so they load
// alongside the page of employees instead of before it — one round trip
// saved on a page that is otherwise two fast queries.
const [orgMaps, { data: employeesData, count }] = await Promise.all([loadOrgMaps(supabase), query]);
const employees = employeesData ?? [];
const totalPages = Math.max(1, Math.ceil((count ?? 0) / PAGE_SIZE));
const { orgMaps, employees, count, placements, ueberPosition } = await withUser(await currentUserId(), async (tx) => {
// Die Referenzdaten zuerst: der Bereichsfilter braucht den Teilbaum.
// „Produktion" meint die Abteilungen und Teams darunter — in der Einheit
// selbst sitzt nur die Bereichsleitung.
const orgMaps = await loadOrgMaps(tx);
const unitFilter = params.division && orgMaps.units.has(params.division) ? params.division : null;
// Eine Filterkette, zwei Abfragen: eine für die Seite, eine für die
// Gesamtzahl. Am direkten Zugang teilen sie sich denselben Aufbau —
// vorher brauchte es zwei getrennte Select-Formen, weil der Typparser der
// API-Schicht einen bedingt zusammengesetzten Select-String nicht
// auflösen konnte.
// Der Ausdrucksbauer wird durchgereicht, damit dieselbe Filterkette
// einmal für die Seite und einmal für die Zählung in *einer* Abfrage
// stehen kann.
const base = (nurNamen: boolean, eb: OrgEb = tx as never) => {
let q = eb.selectFrom("employees");
if (unitFilter) {
// Nach Organisationseinheit gefiltert wird über die *laufende*
// Besetzung. Als EXISTS, damit eine Person nicht mehrfach erscheint,
// wenn sie über die Zeit mehrere Zuordnungen hatte.
const units = subtreeOf(orgMaps, unitFilter);
q = q.where((eb) =>
eb.exists(
eb
.selectFrom("position_assignments as a")
.innerJoin("om_positions as p", "p.id", "a.position_id")
.select("a.id")
.whereRef("a.employee_id", "=", "employees.id")
// Laufend **oder noch bevorstehend**: `valid_to is null` allein
// liess jede Person mit vorgemerktem Austritt aus der Einheit
// verschwinden — terminate_employee setzt das Ende schon beim
// Erfassen, Monate vor dem Tag. Gemeldet im Test vom 29.09.
// (C.09). Das Ende ist ausschliessend, deshalb `>` und nicht
// `>=`. Kein `valid_from <= heute`: ein geplanter Eintritt
// gehört in die Liste, sonst fiele er aus dem Einheitenfilter,
// obwohl der Status „Geplant" ihn ausdrücklich führt.
.where((e) => e.or([e("a.valid_to", "is", null), e("a.valid_to", ">", today)]))
.where("p.org_unit_id", "in", units)
)
);
}
if (params.q) {
const term = params.q.trim();
// `\d`, nicht `d`: der fehlende Backslash liess die Ziffernerkennung
// nie greifen — „1590" wurde als Name gesucht und fand nichts,
// während das Muster auf „ddd" ansprang.
if (istPersonalnummer(term)) {
q = q.where("personnel_number", "=", Number(term));
} else {
// ── Wie hier gesucht wird ──────────────────────────────────
//
// **Wortweise, Reihenfolge egal.** Jedes Wort muss treffen, aber
// nicht in einer bestimmten Ordnung: „Winkler micha" und „micha
// Winkler" führen beide zu Michaela Winkler. Am Stück gesucht stand
// „Michael Winkler" in keinem einzelnen Feld und ergab null Treffer,
// obwohl es vierzehn Winkler gibt.
//
// **Am Wortanfang, nicht mittendrin.** Als Teilzeichenkette traf ein
// „H" auf T-h-omas und Kat-h-arina — bei „Winkler H" kamen alle
// sieben Winkler zurück. Trennzeichen zählen als Wortgrenze, damit
// „dreher" auch „CNC-Dreher:in" findet.
//
// **Namen vor Positionen.** Die Position mitzudurchsuchen ist
// nützlich („dreher"), darf aber eine Namenssuche nicht verwässern:
// bei „Winkler M" tauchten sonst Karin Winkler (Montagemitarbeiterin)
// und Katharina Winkler (Maschinenbedienerin) auf, weil ihre
// Position mit M beginnt. Deshalb wird zuerst nur über die Namen
// gesucht; nur wenn das *nichts* findet, kommt die Position dazu.
// Eine feste Mindestlänge fürs Wort wäre die einfachere Regel, aber
// jede Grenze wäre geraten — diese hier ergibt sich aus den Daten.
//
// Der Trigramm-Index auf dem zusammengesetzten Namen greift bei
// diesem Ausdruck nicht mehr. Bei knapp neunhundert Zeilen liest
// Postgres die Tabelle in wenigen Millisekunden; ein Index auf
// demselben Ausdruck holt das zurück, sobald das nicht mehr stimmt.
// Die Trennzeichen stehen in lib/employee-search.ts, weil die
// Eingabe an denselben zerlegt werden muss — standen sie nur hier,
// fand „Müller-Weiß" nichts (C.08).
const heuhaufen = nurNamen
? sql<string>`translate(lower(first_name || ' ' || last_name), ${TRENNZEICHEN}, ${TRENNZEICHEN_ERSATZ})`
: sql<string>`translate(lower(first_name || ' ' || last_name || ' ' || job_title), ${TRENNZEICHEN}, ${TRENNZEICHEN_ERSATZ})`;
q = q.where((eb) =>
eb.and(
// Als Parameter gebunden, nicht in die Abfrage geschrieben.
suchMuster(term).map(([amAnfang, nachLeerzeichen]) =>
eb.or([eb(heuhaufen, "like", amAnfang), eb(heuhaufen, "like", nachLeerzeichen)])
)
)
);
}
}
// Derived from the dates, not read off employees.status — see
// lib/employee-status-filter.ts for why the two can disagree.
if (statuses.length > 0) {
q = q.where((eb) => derivedStatusFilter(eb, statuses, today) ?? eb.val(true));
}
if (params.location) q = q.where("location_id", "=", params.location);
return q;
};
// Erst nachsehen, ob die Namen allein etwas hergeben. Nur wenn nicht,
// wird die Position mitgesucht — eine zusätzliche, sehr kleine Abfrage,
// und nur bei einer Textsuche.
const sucheNachNamen = Boolean(params.q) && !istPersonalnummer(params.q!.trim());
const namensTreffer = sucheNachNamen
? Number((await base(true).select(({ fn }) => fn.countAll<string>().as("anzahl")).executeTakeFirst())?.anzahl ?? 0)
: 0;
const nurNamen = sucheNachNamen && namensTreffer > 0;
// Seite und Gesamtzahl in *einer* Rundreise. Als Promise.all sah das nach
// Gleichzeitigkeit aus und war keine: eine Transaktion hängt an einer
// Verbindung, und darüber laufen Abfragen nacheinander (lib/db/json.ts).
const { rows, total } = await tx
.selectNoFrom((eb) => [
jsonArrayFrom(
base(nurNamen, eb)
.select([
"id",
"first_name",
"last_name",
"personnel_number",
"job_title",
"location_id",
"entry_date",
"employment_type",
"weekly_hours",
// Nicht `status`: der Chip leitet ab, wie der Filter es tut —
// siehe components/ui/StatusChip.tsx. Drei Spalten mehr auf
// fünfzehn Zeilen, keine zusätzliche Rundreise.
"exit_date",
"karenz_start_date",
"karenz_return_date",
"absence_type",
])
.$call((q) => sortiere(q, sortFeld, sortRichtung, today))
.limit(PAGE_SIZE)
.offset((page - 1) * PAGE_SIZE)
).as("rows"),
jsonObjectFrom(base(nurNamen, eb).select(({ fn }) => fn.countAll<string>().as("anzahl"))).as("total"),
])
.executeTakeFirstOrThrow();
// Die Einordnung kommt über die Planstelle — nur für die 15 Zeilen dieser
// Seite, nicht für den ganzen Bestand.
const placements = await loadPlacements(tx, { asOf: today, employeeIds: rows.map((e) => e.id) });
return {
orgMaps,
employees: rows,
count: Number(total?.anzahl ?? 0),
placements,
// Für den Hinweis über der Liste: wurde nach Namen gesucht, und hat es
// gereicht?
ueberPosition: sucheNachNamen && !nurNamen,
};
});
const totalPages = Math.max(1, Math.ceil(count / PAGE_SIZE));
return (
<div className="flex flex-col gap-4">
<Suspense>
<EmployeeFilters divisions={orgMaps.divisionList} locations={orgMaps.locationList} />
<EmployeeFilters units={orgMaps.unitList} depthOf={orgMaps.depthOf} locations={orgMaps.locationList} />
</Suspense>
<p className="text-sm text-ink-muted">{count ?? 0} Mitarbeiter:innen gefunden</p>
<p className="text-sm text-ink-muted">
{count ?? 0} Mitarbeiter:innen gefunden
{/* Wenn kein Name passte, wurde nach der Position gesucht. Ohne diesen
Hinweis wirkt das Ergebnis, als hätte die Suche etwas erfunden. */}
{ueberPosition && (count ?? 0) > 0 && (
<span className="text-ink-muted"> · kein Namenstreffer, gesucht nach Position</span>
)}
</p>
<div className={`overflow-x-auto ${CARD_CLASS}`}>
{/* Zur zweiten Achse siehe den Kommentar auf der Protokollseite: ohne
`overflow-y-hidden` stuft CSS sie auf `auto` hoch, und die Karte
bekommt eine senkrechte Leiste, die nichts bewirkt. */}
<div className={`overflow-x-auto overflow-y-hidden ${CARD_CLASS}`}>
<table className="w-full min-w-[800px] text-sm">
<thead>
<tr className="border-b border-border bg-surface text-left text-[11px] font-bold uppercase tracking-wider text-ink-muted">
<th className="px-4 py-2.5">Mitarbeiter:in</th>
<th className="px-4 py-2.5">Pers.-Nr.</th>
<th className="px-4 py-2.5">Bereich/Team</th>
<th className="px-4 py-2.5">Standort</th>
<th className="px-4 py-2.5">Eintritt</th>
<th className="px-4 py-2.5">Beschäftigung</th>
<th className="px-4 py-2.5">Status</th>
{SORTIERFELDER.map((f) => {
const aktiv = f.value === sortFeld;
return (
// `aria-sort` sagt einem Screenreader, welche Spalte die
// Reihenfolge bestimmt und in welche Richtung — der Pfeil
// allein ist für ihn nicht da.
<th
key={f.value}
scope="col"
aria-sort={aktiv ? (sortRichtung === "asc" ? "ascending" : "descending") : "none"}
className="px-4 py-2.5"
>
<Link
href={sortHref(params, f.value, sortFeld, sortRichtung)}
// `title` nennt aus, was der Pfeil andeutet: was der
// nächste Klick tut, nicht was gerade gilt.
title={
aktiv && sortRichtung === "asc"
? `${f.label} absteigend sortieren`
: `${f.label} aufsteigend sortieren`
}
className={`group inline-flex items-center gap-1 rounded transition-colors hover:text-ink focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500 ${
aktiv ? "text-ink" : ""
}`}
>
{f.label}
{/* Der Pfeil steht immer da, nur blass, solange die
Spalte nicht sortiert: sonst springt die Kopfzeile
beim Klicken um eine Pfeilbreite. */}
<span aria-hidden className={aktiv ? "text-brand-600" : "text-ink-muted/30 group-hover:text-ink-muted"}>
{aktiv && sortRichtung === "desc" ? "▼" : "▲"}
</span>
</Link>
</th>
);
})}
</tr>
</thead>
<tbody>
{employees.map((e) => {
const { division, team } = breadcrumbFor(orgMaps, e.division_id, e.team_id);
const placement = placements.get(e.id);
const unit = unitOf(orgMaps, placement?.orgUnitId);
const location = e.location_id ? orgMaps.locations.get(e.location_id) : undefined;
return (
// border-subtle between rows: the full-strength border made
@@ -111,18 +360,26 @@ export default async function EmployeesPage({ searchParams }: EmployeesPageProps
<Avatar firstName={e.first_name} lastName={e.last_name} />
<div className="min-w-0">
<div className="truncate font-semibold text-ink">
{e.first_name} {e.last_name}
{fmtName(e.first_name, e.last_name)}
</div>
<div className="truncate text-xs text-ink-muted">{e.job_title}</div>
<div className="truncate text-xs text-ink-muted">{placement?.jobTitle ?? e.job_title}</div>
</div>
</Link>
</td>
{/* tabular-nums keeps the numeric columns aligned down the
page instead of jittering per row. */}
<td className="px-4 py-2.5 tabular-nums text-ink-body">{e.personnel_number}</td>
<td className="px-4 py-2.5 text-ink-body">
<div>{division?.name ?? "–"}</div>
<div className="text-xs text-ink-muted">{team?.name ?? "–"}</div>
{/* Nur die eigene Einheit, egal auf welcher Ebene sie hängt.
Darüber stand der Bereich; der Kunde wollte ihn weg, weil
seine Bereiche CEO, CFO, COO heissen und über jedem Namen
dasselbe wiederholten. Der ganze Weg von oben steht
weiterhin im `title` — eine Einheit wie „Shopleitung"
sagt allein nicht, welche gemeint ist. */}
<td
className="px-4 py-2.5 text-ink-body"
title={breadcrumbLabel(orgMaps, placement?.orgUnitId)}
>
{unit?.name ?? "–"}
</td>
<td className="px-4 py-2.5 text-ink-body">{location?.name ?? "–"}</td>
<td className="px-4 py-2.5 tabular-nums text-ink-body">{fmtDate(e.entry_date)}</td>
@@ -130,7 +387,7 @@ export default async function EmployeesPage({ searchParams }: EmployeesPageProps
{e.employment_type} · <span className="tabular-nums">{e.weekly_hours}h</span>
</td>
<td className="px-4 py-2.5">
<StatusChip status={e.status} entryDate={e.entry_date} absenceType={e.absence_type} />
<StatusChip employee={e} asOf={today} />
</td>
</tr>
);

View File

@@ -8,7 +8,7 @@ import { Button, LINK_BUTTON_CLASS } from "@/components/ui/Button";
// Without this file a failed render drops the user on Next.js's own error
// screen — no navigation, no way back, and in production just "a client-side
// exception occurred". `reset()` re-renders the segment, which is enough for
// the common case of a transient Supabase timeout.
// the common case of a transient database timeout.
export default function AppError({ error, reset }: { error: Error & { digest?: string }; reset: () => void }) {
useEffect(() => {
console.error("Route error:", error);

16
app/(app)/import/page.tsx Normal file
View File

@@ -0,0 +1,16 @@
import { ImportWorkbench } from "@/components/import/ImportWorkbench";
export const metadata = { title: "Import" };
export default function ImportPage() {
return (
<div className="flex flex-col gap-4">
<p className="max-w-prose text-sm text-ink-muted">
Übernahme aus einer Datei — Organisation, Planstellen, Personen, Historie und Angehörige. Angelegt wird nur;
bestehende Datensätze werden nie überschrieben. Geprüft wird vor dem Schreiben, und geschrieben wird alles
zusammen oder gar nichts.
</p>
<ImportWorkbench />
</div>
);
}

View File

@@ -2,36 +2,41 @@ import { redirect } from "next/navigation";
import type { ReactNode } from "react";
import { HireWizardProvider } from "@/components/hire/HireWizardContext";
import { AppShell } from "@/components/shell/AppShell";
import { loadOpenNotes } from "@/lib/notes";
import { loadOpenPositions } from "@/lib/positions";
import { createClient } from "@/lib/supabase/server";
import { currentUserId } from "@/lib/auth/session";
import { withUser } from "@/lib/db";
import { loadShellData } from "@/lib/shell-data";
export default async function AppLayout({ children }: { children: ReactNode }) {
const supabase = await createClient();
const {
data: { user },
} = await supabase.auth.getUser();
if (!user) redirect("/login");
const userId = await currentUserId();
if (!userId) redirect("/login");
// Defense in depth: proxy.ts already redirects any non-active-HR session
// away before this layout ever renders. Re-checking here means a gap in
// the proxy matcher (or a future route added outside it) still fails
// closed instead of silently granting access — see docs/security.md.
const { data: profile } = await supabase.from("profiles").select("full_name, email, role, is_active").eq("id", user.id).maybeSingle();
if (profile?.role !== "hr" || profile?.is_active !== true) redirect("/login");
// Alles in *einer* Transaktion, weil nur dort der Sitzungskontext gilt —
// und damit nebenbei auf einem einheitlichen Lesestand. Was dabei in wie
// vielen Rundreisen gelesen wird, steht in lib/shell-data.ts.
const ergebnis = await withUser(userId, (tx) => loadShellData(tx, userId));
const userLabel = profile.full_name || profile.email || user.email || "";
// Hier — und nicht im Proxy — fällt diese Entscheidung: der Proxy hat keine
// Datenbankverbindung. Sie wird bei jedem Aufbau frisch gestellt, eine
// entzogene Freischaltung wirkt also sofort statt erst mit dem nächsten
// Sitzungstoken.
//
// Beide Umleitungen sind Bedienkomfort, keine Absicherung: wer sie umgeht,
// bekommt trotzdem keine Zeile, weil die RLS-Policies dieselbe Frage stellen
// (is_hr_user()). Ohne sie stünde die Person nur vor einer leeren Anwendung
// und wüsste nicht, warum.
if (ergebnis.status === "passwort_wechseln") redirect("/passwort-aendern");
const [openPositions, locationsRes, draftsRes, openNotes] = await Promise.all([
loadOpenPositions(supabase),
supabase.from("locations").select("id, name, country").order("name"),
supabase.from("hire_drafts").select("id, step, payload, updated_at").eq("created_by", user.id).order("updated_at", { ascending: false }),
loadOpenNotes(supabase),
]);
// Ohne den Grund in der Adresse stünde die Person vor einer wortlosen
// Anmeldeseite und versuchte es endlos erneut.
if (ergebnis.status === "kein_zugang") redirect("/login?error=no_hr_access");
const data = ergebnis.daten;
const userLabel = data.profile.full_name || data.profile.email || "";
return (
<HireWizardProvider openPositions={openPositions} locations={locationsRes.data ?? []} drafts={draftsRes.data ?? []}>
<AppShell userLabel={userLabel} openNotes={openNotes}>
<HireWizardProvider openPositions={data.openPositions} locations={data.locations} drafts={data.drafts}>
<AppShell userLabel={userLabel} openNotes={data.openNotes} kollegen={data.kollegen}>
{children}
</AppShell>
</HireWizardProvider>

View File

@@ -1,5 +1,5 @@
// Every page in this group is server-rendered per request (they all read
// from Supabase), so without this the browser sits on the previous page with
// from the database), so without this the browser sits on the previous page with
// no feedback until the server answers — on the employee list, long enough
// to look broken.
export default function Loading() {

View File

@@ -1,10 +1,11 @@
import { Suspense } from "react";
import { OrgChartClient } from "@/components/orgchart/OrgChartClient";
import type { OrgUnitNode } from "@/components/orgchart/types";
import { todayIso } from "@/lib/format";
import { loadOrgAsOf } from "@/lib/orgchart-data";
import { loadOpenPositions } from "@/lib/positions";
import { parseIsoDateParam } from "@/lib/reports";
import { createClient } from "@/lib/supabase/server";
import { currentUserId } from "@/lib/auth/session";
import { withUser } from "@/lib/db";
type SearchParams = { asOf?: string; focus?: string };
@@ -18,32 +19,30 @@ export default async function OrgChartPage({ searchParams }: { searchParams: Pro
// so a junk value can't reach the client as an arbitrary string.
const focusId = params.focus && UUID.test(params.focus) ? params.focus : null;
const supabase = await createClient();
const [org, { data: divisions }, { data: departments }, { data: teams }, openPositions, { data: reorgScenarios }] =
await Promise.all([
loadOrgAsOf(supabase, asOf),
supabase.from("divisions").select("*").order("name"),
supabase.from("departments").select("*"),
supabase.from("teams").select("*"),
loadOpenPositions(supabase),
supabase
.from("reorg_scenarios")
.select("id, name, effective_date, applied, applied_at")
.eq("applied", true)
.order("applied_at", { ascending: false })
.limit(5),
const { org, units } = await withUser(await currentUserId(), async (tx) => {
const [org, units] = await Promise.all([
loadOrgAsOf(tx, asOf),
tx
.selectFrom("org_units")
// valid_from/valid_to nur hier: die Angaben zur Einheit zeigen sie,
// der Druck braucht sie nicht.
.select(["id", "org_number", "name", "parent_id", "unit_type", "valid_from", "valid_to"])
// Zum Stichtag — sonst zeigt die Struktursicht zum 01.01.2020
// Einheiten, die es damals nicht gab (D.06).
.where("valid_from", "<=", asOf)
.where((eb) => eb.or([eb("valid_to", "is", null), eb("valid_to", ">", asOf)]))
.orderBy("org_number")
.execute(),
]);
return { org, units };
});
return (
<Suspense>
<OrgChartClient
employees={org.employees}
divisions={divisions ?? []}
departments={departments ?? []}
teams={teams ?? []}
openPositions={openPositions}
reorgScenarios={reorgScenarios ?? []}
units={units as OrgUnitNode[]}
vacancies={org.vacancies}
asOf={asOf}
today={today}
projectedCount={org.projectedCount}

View File

@@ -0,0 +1,43 @@
import { PrintChart } from "@/components/orgchart/PrintChart";
import type { OrgUnitNode } from "@/components/orgchart/types";
import { currentUserId } from "@/lib/auth/session";
import { withUser } from "@/lib/db";
import { todayIso } from "@/lib/format";
import { loadOrgAsOf } from "@/lib/orgchart-data";
import { buildPrintModel } from "@/lib/orgchart-print";
import { parseIsoDateParam } from "@/lib/reports";
export const metadata = { title: "Organigramm drucken" };
type SearchParams = { asOf?: string };
// Eigene Route statt eines Druckstils auf der Organigramm-Seite.
//
// Die interaktive Ansicht ist eine Leinwand mit Zoom und Verschiebung; was
// davon auf Papier landet, hängt vom Zufallsstand der Ansicht ab. Hier wird
// stattdessen aus denselben Daten eine Seitenfolge gebaut, und der Stichtag
// wird aus der Adresse übernommen — wer im Organigramm einen Stichtag
// eingestellt hat, druckt genau den.
export default async function OrgChartPrintPage({ searchParams }: { searchParams: Promise<SearchParams> }) {
const params = await searchParams;
const today = todayIso();
const asOf = parseIsoDateParam(params.asOf) ?? today;
const { org, units } = await withUser(await currentUserId(), async (tx) => {
const [org, units] = await Promise.all([
loadOrgAsOf(tx, asOf),
tx
.selectFrom("org_units")
.select(["id", "org_number", "name", "parent_id", "unit_type"])
.where((eb) => eb.or([eb("valid_to", "is", null), eb("valid_to", ">", asOf)]))
.where("valid_from", "<=", asOf)
.orderBy("org_number")
.execute(),
]);
return { org, units };
});
const model = buildPrintModel(units as OrgUnitNode[], org.employees, org.vacancies);
return <PrintChart model={model} asOf={asOf} today={today} />;
}

View File

@@ -1,12 +1,18 @@
import { ChevronRight } from "lucide-react";
import Link from "next/link";
import { Fragment, Suspense } from "react";
import { AnstehendFilter } from "@/components/dashboard/AnstehendFilter";
import { AnstehendListe, type AnstehendEintrag } from "@/components/dashboard/AnstehendListe";
import { DraftsCard } from "@/components/dashboard/DraftsCard";
import { Card, CARD_CLASS, CardTitle } from "@/components/ui/Card";
import { actionBadgeStyle } from "@/lib/colors";
import { addDaysIso, fmtDate, todayIso } from "@/lib/format";
import { eventBadgeStyle, eventDotStyle } from "@/lib/colors";
import { istEingeschraenkt, parseArten, parseZeitraum } from "@/lib/dashboard-filter";
import { loadDashboardData } from "@/lib/dashboard-data";
import { addDaysIso, fmtName, todayIso } from "@/lib/format";
import { divisionOf } from "@/lib/org";
import { deriveStatusAsOf } from "@/lib/reports";
import { createClient } from "@/lib/supabase/server";
import { fetchAllRows } from "@/lib/supabase/query";
import { currentUserId } from "@/lib/auth/session";
import { withUser } from "@/lib/db";
// Each KPI carries a colour already; the accent bar repeats it in a second
// channel so the tiles are scannable as a row rather than six identical
@@ -17,37 +23,46 @@ const TONE: Record<string, { text: string; bar: string }> = {
danger: { text: "text-danger-text", bar: "bg-danger-text" },
warning: { text: "text-warning-text", bar: "bg-warning-text" },
brand: { text: "text-brand-700", bar: "bg-brand-500" },
// Geplante Eintritte: eine Ankündigung, kein Befund. „info" ist der Ton,
// den die Statuschips für „Geplant" ohnehin tragen.
info: { text: "text-info-text", bar: "bg-info-text" },
};
const DOT_STYLES: Record<string, string> = {
Eintritt: "bg-success-text",
Wiedereintritt: "bg-success-text",
Rückkehr: "bg-success-text",
Austritt: "bg-danger-text",
Versetzung: "bg-info-text",
Beförderung: "bg-purple-text",
Reorganisation: "bg-purple-text",
Karenz: "bg-warning-text",
Vertragsänderung: "bg-warning-text",
Stammdatenänderung: "bg-warning-text",
Gehaltsanpassung: "bg-warning-text",
/** Eine Kennzahl auf der Übersicht. */
type Kachel = { label: string; value: string | number; tone: keyof typeof TONE; href: string };
/**
* Wie viele Spalten die Überschrift einer Gruppe überspannt — nach der Zahl
* ihrer Kacheln.
*
* Ausgeschrieben und nicht als `span var(--kacheln)`: Tailwind erzeugt nur
* Klassen, die als Zeichenkette im Quelltext stehen, und eine aus einer
* Variablen berechnete Spannweite wäre zur Bauzeit nicht zu sehen. Die
* Tabelle deckt jede mögliche Gruppengrösse bis zur Rasterbreite ab; ein
* Zugriff daneben gäbe `undefined` und damit eine Überschrift über einer
* einzigen Spalte — auffällig genug, um bemerkt zu werden.
*/
const SPALTEN_SPAN: Record<number, string> = {
1: "xl:col-span-1",
2: "xl:col-span-2",
3: "xl:col-span-3",
4: "xl:col-span-4",
5: "xl:col-span-5",
6: "xl:col-span-6",
7: "xl:col-span-7",
8: "xl:col-span-8",
};
const KIND_LABEL = { hire: "Eintritt", exit: "Austritt", return: "Rückkehr aus Abwesenheit" } as const;
export default async function DashboardPage() {
const supabase = await createClient();
const {
data: { user },
} = await supabase.auth.getUser();
const { data: drafts } = user
? await supabase
.from("hire_drafts")
.select("id, step, payload, updated_at")
.eq("created_by", user.id)
.order("updated_at", { ascending: false })
: { data: [] };
// Die Tabelle, die hier stand, ist nach lib/colors.ts gewandert: Punkt und
// Chip derselben Zeile kamen aus zwei getrennten Verzeichnissen, und eines
// davon war das falsche. Jetzt leiten beide aus EVENT_CATEGORY ab und koennen
// nicht mehr auseinanderlaufen.
export default async function DashboardPage({
searchParams,
}: {
searchParams: Promise<{ tage?: string; arten?: string }>;
}) {
// Built as strings, not by round-tripping a local Date through
// toISOString(): in any positive-offset zone new Date(year, 0, 1) is still
// the previous year in UTC, which shifted the whole YTD window a day early
@@ -55,8 +70,20 @@ export default async function DashboardPage() {
const today = todayIso();
const year = today.slice(0, 4);
const yearStart = `${year}-01-01`;
const yearEnd = `${year}-12-31`;
const in60Iso = addDaysIso(today, 60);
// Das obere Ende des YTD-Fensters ist **heute**. Hier stand der 31.12., also
// das ganze Kalenderjahr — womit die Kacheln auch zählten, was erst
// bevorsteht (B.02).
const ytdBis = today;
// Der Vorschauzeitraum ist einstellbar, und mit ihm, was überhaupt geladen
// wird. Deshalb steht die Auswahl in der Adresse und nicht im Browser: 90
// statt 60 Tage bringt Zeilen ins Spiel, die sonst nirgends lägen.
const params = await searchParams;
const zeitraum = parseZeitraum(params.tage);
const arten = parseArten(params.arten);
const bisIso = addDaysIso(today, zeitraum);
const userId = await currentUserId();
// Headcount, FTE, Karenz and the division bars all come from one full read
// and the *derived* status, not from the `employees.status` column.
@@ -66,69 +93,20 @@ export default async function DashboardPage() {
// planned hire whose start date has passed, or a Karenz that ended without
// anyone recording the return, made the dashboard and the Berichte page
// disagree about the same headcount. Same derivation, same numbers.
// It also replaces four separate count queries with one.
const [
const {
drafts,
staffRows,
hiresYtdRes,
exitsYtdRes,
openPositionsRes,
divisionsRes,
upcomingHiresRes,
upcomingExitsRes,
upcomingReturnsRes,
historyRes,
] = await Promise.all([
fetchAllRows(() =>
supabase
.from("employees")
.select("weekly_hours, division_id, entry_date, exit_date, karenz_start_date, karenz_return_date")
.order("id")
),
// Entries/exits count history events, which is what the linked report
// counts too. `entry_date` would also sweep up rehires, whose event is
// logged as 'Wiedereintritt' — the tile and its destination then showed
// different numbers for the same year.
supabase
.from("employee_history")
.select("id", { count: "exact", head: true })
.in("event_type", ["Eintritt", "Wiedereintritt"])
.gte("event_date", yearStart)
.lte("event_date", yearEnd),
supabase
.from("employee_history")
.select("id", { count: "exact", head: true })
.eq("event_type", "Austritt")
.gte("event_date", yearStart)
.lte("event_date", yearEnd),
supabase.from("positions").select("id", { count: "exact", head: true }).eq("status", "open"),
supabase.from("divisions").select("id, name"),
supabase
.from("employees")
.select("id, first_name, last_name, entry_date")
.eq("status", "Geplant")
.gte("entry_date", today)
.lte("entry_date", in60Iso),
supabase
.from("employees")
.select("id, first_name, last_name, exit_date")
.not("exit_date", "is", null)
.gte("exit_date", today)
.lte("exit_date", in60Iso),
supabase
.from("employees")
.select("id, first_name, last_name, karenz_return_date")
.eq("status", "Karenz")
.not("karenz_return_date", "is", null)
.gte("karenz_return_date", today)
.lte("karenz_return_date", in60Iso),
supabase
.from("employee_history")
.select("id, employee_id, event_date, event_type, description")
.order("event_date", { ascending: false })
.order("created_at", { ascending: false })
.limit(10),
]);
hiresYtd,
exitsYtd,
openPositions,
orgMaps,
placements,
upcomingHires,
upcomingExits,
upcomingReturns,
upcomingNotes,
history,
} = await withUser(userId, (tx) => loadDashboardData(tx, { userId, today, yearStart, ytdBis, bisIso, arten }));
// "Aktiv" means status Aktiv — somebody on Karenz is employed but not
// active, and is counted by its own tile instead. FTE follows the same
// set: Karenz contributes no capacity, so including it would overstate
@@ -143,45 +121,53 @@ export default async function DashboardPage() {
const karenzCount = staffRows.filter((row) => statusOf(row) === "Karenz").length;
const fte = activeStaff.reduce((sum, row) => sum + Number(row.weekly_hours), 0) / 38.5;
// Der Bereich einer Person steht nicht mehr auf ihr; er ergibt sich aus der
// Einheit ihrer Planstelle und deren Vorfahren. Die Bereichsleitung selbst
// sitzt *am* Bereich, ihre Leute darunter — beide landen über die
// Vorfahrenkette im selben Balken.
const headcountByDivision = new Map<string, number>();
for (const row of activeStaff) {
if (!row.division_id) continue;
headcountByDivision.set(row.division_id, (headcountByDivision.get(row.division_id) ?? 0) + 1);
const division = divisionOf(orgMaps, placements.get(row.id)?.orgUnitId);
if (!division) continue;
headcountByDivision.set(division.id, (headcountByDivision.get(division.id) ?? 0) + 1);
}
const divisionBars = (divisionsRes.data ?? [])
const divisionBars = orgMaps.unitList
.filter((u) => u.unit_type === "Bereich")
.map((d) => ({ name: d.name, count: headcountByDivision.get(d.id) ?? 0 }))
.sort((a, b) => b.count - a.count);
const maxDivisionCount = Math.max(1, ...divisionBars.map((d) => d.count));
type UpcomingItem = { id: string; label: string; date: string; kind: keyof typeof KIND_LABEL };
const upcoming: UpcomingItem[] = [
...(upcomingHiresRes.data ?? []).map((e) => ({
const upcomingAlle: AnstehendEintrag[] = [
...(upcomingHires).map((e) => ({
id: e.id,
label: `${e.first_name} ${e.last_name}`,
employeeId: e.id,
label: fmtName(e.first_name, e.last_name),
date: e.entry_date,
kind: "hire" as const,
})),
...(upcomingExitsRes.data ?? []).map((e) => ({
...(upcomingExits).map((e) => ({
id: e.id,
label: `${e.first_name} ${e.last_name}`,
employeeId: e.id,
label: fmtName(e.first_name, e.last_name),
date: e.exit_date!,
kind: "exit" as const,
})),
...(upcomingReturnsRes.data ?? []).map((e) => ({
...(upcomingReturns).map((e) => ({
id: e.id,
label: `${e.first_name} ${e.last_name}`,
employeeId: e.id,
label: fmtName(e.first_name, e.last_name),
date: e.karenz_return_date!,
kind: "return" as const,
})),
]
.sort((a, b) => a.date.localeCompare(b.date))
.slice(0, 8);
const historyEmployeeIds = Array.from(new Set((historyRes.data ?? []).map((h) => h.employee_id)));
const historyEmployeesRes = historyEmployeeIds.length
? await supabase.from("employees").select("id, first_name, last_name").in("id", historyEmployeeIds)
: { data: [] as { id: string; first_name: string; last_name: string }[] };
const employeeNameById = new Map((historyEmployeesRes.data ?? []).map((e) => [e.id, `${e.first_name} ${e.last_name}`]));
...(upcomingNotes).map((n) => ({
id: n.id,
employeeId: n.employee_id!,
label: fmtName(n.first_name, n.last_name),
hinweis: n.note_text,
date: n.due_date!,
kind: "note" as const,
})),
].sort((a, b) => a.date.localeCompare(b.date));
// Each tile links to the view that shows what it counts, with the filters
// pre-applied.
@@ -193,49 +179,142 @@ export default async function DashboardPage() {
// and rehire_employee sets entry_date but logs the event as
// 'Wiedereintritt'. A year with rehires therefore shows a slightly higher
// number on the tile than in the linked report.
const kpis = [
// ── Warum die Kacheln in Gruppen stehen ────────────────────────────
//
// Acht Zahlen nebeneinander sind acht Zahlen. Sie beantworten aber drei
// verschiedene Fragen: wie viele sind da, was hat sich bewegt, was ist
// offen. Ohne Überschrift muss man jede Beschriftung einzeln lesen, um das
// herauszufinden — mit ihr sieht man es, bevor man liest.
//
// Die Einteilung und die Reihenfolge kommen aus einem Entwurf des Kunden
// (E-Mail vom 16.09.2026). „Aktives Dienstverhältnis" steht darin bewusst
// **vorn**: es ist die Bezugsgrösse fast jeder Personalkennzahl, und wer
// eine Quote bildet, greift zuerst danach.
const kpiGruppen: { titel: string; kacheln: Kachel[] }[] = [
{
label: "Aktive Mitarbeiter:innen",
value: activeCount,
tone: "default",
href: "/employees?status=Aktiv",
},
{ label: "FTE", value: fte.toFixed(1), tone: "default", href: "/reports?mode=snapshot&measure=fte&status=Aktiv" },
{
label: "Eintritte (Jahr)",
value: hiresYtdRes.count ?? 0,
tone: "success",
href: `/reports?mode=events&eventType=Eintritt&from=${yearStart}&to=${yearEnd}`,
titel: "Personalstand",
kacheln: [
// Nicht dasselbe wie „Aktive Mitarbeiter:innen" daneben: dort steht,
// wer heute arbeitet, hier, mit wem ein Vertrag läuft —
// Langzeitabwesende eingeschlossen. Sichtbar waren 805 und 10,
// addieren musste man selbst.
// Die Namen der beiden stehen so fest: Max am 30.09. — „Es gibt zwei
// Headcounts: Headcount Aktiv (nur Aktive) und Headcount Aktives
// Dienstverhältnis (Aktiv + Langzeitabwesenheit)". Vorher hiess nur die
// rechte Kachel „(HC)", und im Bericht stand daneben „Headcount" für
// eine dritte Zahl — dasselbe Wort für Verschiedenes (N.02).
{
label: "Headcount Aktives Dienstverhältnis",
value: activeCount + karenzCount,
tone: "default",
// Mit Komma, nicht zweimal `status=`: die Liste liest den Parameter
// als *eine* Zeichenkette und trennt selbst. Zweimal übergeben macht
// Next daraus ein Array, und die Seite scheiterte an `.split(",")`.
href: "/employees?status=Aktiv,Karenz",
},
{ label: "Headcount Aktiv", value: activeCount, tone: "default", href: "/employees?status=Aktiv" },
{ label: "Langzeitabwesende", value: karenzCount, tone: "warning", href: "/employees?status=Karenz" },
// Ohne Zeitgrenze — anders als die Karte „Anstehend" darunter, die nur
// den eingestellten Vorschauzeitraum zeigt. Ein Eintritt in vier
// Monaten ist vereinbart und zählt, auch wenn er dort nicht auftaucht.
{
label: "Geplante Eintritte",
value: staffRows.filter((row) => statusOf(row) === "Geplant").length,
tone: "info",
href: "/employees?status=Geplant",
},
{ label: "Aktive FTE", value: fte.toFixed(1), tone: "default", href: "/reports?mode=snapshot&measure=fte&status=Aktiv" },
],
},
{
label: "Austritte (Jahr)",
value: exitsYtdRes.count ?? 0,
tone: "danger",
href: `/reports?mode=events&eventType=Austritt&from=${yearStart}&to=${yearEnd}`,
titel: "Personalbewegung",
kacheln: [
{
// YTD: seit Jahresbeginn bis heute, nicht das ganze Kalenderjahr.
// Der Verweis trägt denselben Zeitraum — sonst zeigte der Bericht
// eine andere Zahl als die Kachel, über die man ihn geöffnet hat.
label: "Eintritte (YTD)",
value: hiresYtd,
tone: "success",
href: `/reports?mode=events&eventType=Eintritt&from=${yearStart}&to=${ytdBis}`,
},
{
label: "Austritte (YTD)",
value: exitsYtd,
tone: "danger",
href: `/reports?mode=events&eventType=Austritt&from=${yearStart}&to=${ytdBis}`,
},
],
},
{
titel: "Recruiting & Vakanzen",
kacheln: [{ label: "Offene Positionen", value: openPositions.length, tone: "brand", href: "/positions" }],
},
{ label: "Langzeitabwesend", value: karenzCount, tone: "warning", href: "/employees?status=Karenz" },
{ label: "Offene Positionen", value: openPositionsRes.count ?? 0, tone: "brand", href: "/positions" },
];
return (
<div className="flex flex-col gap-6">
{drafts && drafts.length > 0 && <DraftsCard drafts={drafts} />}
<div className="grid grid-cols-2 gap-3 sm:grid-cols-3 lg:grid-cols-6">
{kpis.map((kpi) => (
<Link
key={kpi.label}
href={kpi.href}
className={`${CARD_CLASS} group relative overflow-hidden p-4 pl-5 transition-shadow hover:shadow-[var(--shadow-card-hover)] focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500`}
>
<span className={`absolute inset-y-0 left-0 w-1 ${TONE[kpi.tone].bar}`} aria-hidden />
{/* Number first in the visual order: it is what the eye is
looking for, and the label only qualifies it. */}
<div className={`text-3xl font-extrabold leading-none tabular-nums ${TONE[kpi.tone].text}`}>{kpi.value}</div>
<div className="mt-1.5 flex items-center gap-1 text-xs font-semibold leading-tight text-ink-muted">
{kpi.label}
<ChevronRight className="h-3 w-3 shrink-0 opacity-0 transition-opacity group-hover:opacity-100" aria-hidden />
</div>
</Link>
{drafts.length > 0 && <DraftsCard drafts={drafts} />}
{/* ── Ein Raster, nicht drei nebeneinandergestellte ──────────────
Alle acht Kacheln liegen in **einem** Raster mit acht gleichen
Spalten und einem einzigen Abstandswert. Nur so sind sie gleich
breit und gleich weit auseinander — unabhängig davon, zu welcher
Gruppe sie gehören.
Die beiden Anläufe davor stellten drei eigene Raster nebeneinander.
Das ging zweimal schief: erst bekam jede Gruppe ein Drittel der
Breite (fünf Kacheln gequetscht, eine mit demselben Platz), dann
einen Anteil nach Kachelzahl — da stimmten die Breiten fast, aber
eben nur fast: eine Gruppe mit fünf Kacheln hat vier Abstände in
sich, eine mit einer keinen, und dieser Unterschied verteilt sich
auf die Kachelbreiten. Gleichmässig wird es erst, wenn alle Kacheln
demselben Raster angehören.
Die Überschriften sitzen in Zeile 1 und überspannen die Spalten
ihrer Gruppe, die Kacheln in Zeile 2. Beide Zeilen entstehen aus
derselben DOM-Reihenfolge (Überschrift, ihre Kacheln, nächste
Überschrift …) — die ist für Vorlesegeräte die richtige, und die
ausdrückliche Zeilenangabe sortiert sie fürs Auge.
Unterhalb der grossen Breite gibt es keine Zeilenangabe: dann fliesst
alles der Reihe nach, die Überschrift über die volle Breite und ihre
Kacheln zu zweit darunter. Acht nebeneinander wären auf einem Laptop
unlesbar schmal. */}
<div className="grid grid-cols-2 gap-x-3 gap-y-3 xl:grid-cols-8 xl:gap-y-1.5">
{kpiGruppen.map((gruppe) => (
<Fragment key={gruppe.titel}>
<h2
className={`mt-2 self-end text-[11px] font-bold uppercase tracking-wider text-ink-muted
col-span-2 xl:mt-0 xl:[grid-row:1] ${SPALTEN_SPAN[gruppe.kacheln.length]}`}
>
{gruppe.titel}
</h2>
{gruppe.kacheln.map((kpi) => (
<Link
key={kpi.label}
href={kpi.href}
className={`${CARD_CLASS} group relative overflow-hidden p-4 pl-5 transition-shadow xl:[grid-row:2] hover:shadow-[var(--shadow-card-hover)] focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500`}
>
<span className={`absolute inset-y-0 left-0 w-1 ${TONE[kpi.tone].bar}`} aria-hidden />
{/* Number first in the visual order: it is what the eye is
looking for, and the label only qualifies it.
Kleiner, sobald alle acht in einer Reihe stehen: dort
bleiben je Kachel gut 110 px, und „748.4" braucht in 30 px
Schriftgrad mehr davon, als nach dem Innenabstand übrig
ist. Die Kachel hat `overflow-hidden` — die Zahl wäre also
nicht zu breit, sondern abgeschnitten, und eine
abgeschnittene Kennzahl ist schlimmer als eine kleine. */}
<div className={`text-3xl font-extrabold leading-none tabular-nums xl:text-2xl ${TONE[kpi.tone].text}`}>
{kpi.value}
</div>
<div className="mt-1.5 flex items-center gap-1 text-xs font-semibold leading-tight text-ink-muted">
{kpi.label}
<ChevronRight className="h-3 w-3 shrink-0 opacity-0 transition-opacity group-hover:opacity-100" aria-hidden />
</div>
</Link>
))}
</Fragment>
))}
</div>
@@ -266,38 +345,48 @@ export default async function DashboardPage() {
</Card>
<Card>
<CardTitle className="mb-1">Anstehend (60 Tage)</CardTitle>
<ul className="flex flex-col divide-y divide-border-subtle">
{upcoming.map((item) => (
<li key={`${item.kind}-${item.id}`}>
<Link
href={`/employees/${item.id}`}
className="-mx-2 flex items-center justify-between gap-2 rounded px-2 py-2.5 text-sm hover:bg-surface"
>
<span className="min-w-0">
<span className="block truncate font-semibold text-ink">{item.label}</span>
<span className="text-xs text-ink-muted">{KIND_LABEL[item.kind]}</span>
</span>
<span className="shrink-0 text-xs font-semibold tabular-nums text-ink-muted">{fmtDate(item.date)}</span>
</Link>
</li>
))}
{upcoming.length === 0 && <p className="py-2 text-sm text-ink-muted">Keine anstehenden Ereignisse.</p>}
</ul>
<CardTitle className="mb-2">Anstehend ({zeitraum} Tage)</CardTitle>
{/* useSearchParams braucht eine Suspense-Grenze; ohne sie fällt beim
Bauen die ganze Seite auf Rendern zur Laufzeit zurück. */}
<Suspense fallback={<div className="mb-2 h-9" />}>
<AnstehendFilter zeitraum={zeitraum} arten={arten} />
</Suspense>
<AnstehendListe
eintraege={upcomingAlle}
today={today}
leerText={
istEingeschraenkt(zeitraum, arten)
? "Zu dieser Auswahl steht nichts an."
: "Keine anstehenden Ereignisse."
}
/>
</Card>
<Card>
<CardTitle className="mb-1">Letzte Aktivitäten</CardTitle>
<ul className="flex flex-col divide-y divide-border-subtle">
{(historyRes.data ?? []).map((h) => (
{(history).map((h) => (
<li key={h.id} className="flex gap-2.5 py-2.5">
{/* Dot aligned to the first line of text, not centred on the
whole row, so it stays put as descriptions wrap. */}
<span className={`mt-1.5 h-2 w-2 shrink-0 rounded-full ${DOT_STYLES[h.event_type] ?? "bg-ink-muted"}`} aria-hidden />
<span className={`mt-1.5 h-2 w-2 shrink-0 rounded-full ${eventDotStyle(h.event_type)}`} aria-hidden />
<div className="min-w-0 flex-1">
<div className="flex flex-wrap items-center gap-x-2 gap-y-1">
<span className="text-sm font-semibold text-ink">{employeeNameById.get(h.employee_id) ?? "Unbekannt"}</span>
<span className={`rounded-full px-2 py-0.5 text-[11px] font-semibold ${actionBadgeStyle(h.event_type)}`}>
{/* Der Name führt in die Akte. Ohne den Link war die Karte
eine Sackgasse: man sah, dass etwas passiert ist, und
musste die Person danach in der Liste suchen. */}
{h.first_name && h.last_name ? (
<Link
href={`/employees/${h.employee_id}`}
className="rounded text-sm font-semibold text-ink hover:text-brand-700 hover:underline
focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500"
>
{fmtName(h.first_name, h.last_name)}
</Link>
) : (
<span className="text-sm font-semibold text-ink">Unbekannt</span>
)}
<span className={`rounded-full px-2 py-0.5 text-[11px] font-semibold ${eventBadgeStyle(h.event_type)}`}>
{h.event_type}
</span>
</div>
@@ -305,7 +394,7 @@ export default async function DashboardPage() {
</div>
</li>
))}
{(historyRes.data ?? []).length === 0 && <p className="py-2 text-sm text-ink-muted">Keine Aktivitäten vorhanden.</p>}
{(history).length === 0 && <p className="py-2 text-sm text-ink-muted">Keine Aktivitäten vorhanden.</p>}
</ul>
</Card>
</div>

View File

@@ -1,21 +1,51 @@
import type { UnitOption } from "@/components/positions/CreatePositionModal";
import { PositionsPageClient } from "@/components/positions/PositionsPageClient";
import { daysBetweenIso, toIsoDate } from "@/lib/format";
import { loadOpenPositions } from "@/lib/positions";
import { createClient } from "@/lib/supabase/server";
import { currentUserId } from "@/lib/auth/session";
import { kostenstellenAbfrage } from "@/lib/cost-centers";
import { withUser } from "@/lib/db";
import { jsonArrayFrom } from "@/lib/db/json";
import { daysBetweenIso, todayIso } from "@/lib/format";
import { buildOrgMaps, orgMapsAbfragen } from "@/lib/org";
import { offeneStellenAbfrage, resolveOpenPositions, type OffeneStelle } from "@/lib/positions";
export default async function PositionsPage() {
const supabase = await createClient();
const today = todayIso();
// Teams are only needed for the "Position ausschreiben" dialog's team
// select. The division/department/team headcount overview this page used
// to render was dropped, and with it the two employee-wide aggregation
// queries that fed it.
const [openPositions, { data: teams }] = await Promise.all([
loadOpenPositions(supabase),
supabase.from("teams").select("*").order("name"),
]);
const { openPositions, orgMaps, chiefRows, kostenstellen } = await withUser(await currentUserId(), async (tx) => {
// Alles, was ohne Vorwissen geht, in einer Rundreise (lib/db/json.ts).
const g = await tx
.selectNoFrom((eb) => [
...orgMapsAbfragen(eb),
jsonArrayFrom(offeneStellenAbfrage(eb, today)).as("open"),
jsonArrayFrom(kostenstellenAbfrage(eb, today)).as("kostenstellen"),
// Wo es schon eine gültige Leitungsplanstelle gibt, lässt der
// Unique-Index keine zweite zu — das gehört in den Dialog, nicht in eine
// Fehlermeldung nach dem Absenden.
jsonArrayFrom(
eb.selectFrom("om_positions").select("org_unit_id").where("is_chief", "=", true).where("valid_to", "is", null)
).as("chiefRows"),
])
.executeTakeFirstOrThrow();
const openPositionsWithDays = openPositions.map((p) => ({ ...p, daysOpen: daysBetweenIso(toIsoDate(p.created_at)) }));
const orgMaps = buildOrgMaps(g.units as never, g.locations as never);
return {
orgMaps,
chiefRows: g.chiefRows,
kostenstellen: g.kostenstellen,
openPositions: await resolveOpenPositions(tx, orgMaps, g.open as OffeneStelle[], today),
};
});
return <PositionsPageClient openPositions={openPositionsWithDays} teams={teams ?? []} />;
const withChief = new Set(chiefRows.map((r) => r.org_unit_id));
const units: UnitOption[] = orgMaps.unitList.map((u) => ({
id: u.id,
name: u.name,
unit_type: u.unit_type,
depth: orgMaps.depthOf.get(u.id) ?? 0,
hasChief: withChief.has(u.id),
}));
const openPositionsWithDays = openPositions.map((p) => ({ ...p, daysOpen: daysBetweenIso(p.vacantSince) }));
return <PositionsPageClient openPositions={openPositionsWithDays} units={units} kostenstellen={kostenstellen} />;
}

View File

@@ -6,6 +6,7 @@ import {
parseEventDateParam,
parseEventGroupDimension,
parseEventSplitDimension,
parseEventSubtype,
parseEventType,
parseGroupDimension,
parseIsoDateParam,
@@ -15,10 +16,15 @@ import {
sumValues,
totalForRows,
} from "@/lib/reports";
import { parseCriteria } from "@/lib/report-criteria";
import { loadEventHistory, loadOrgLookups, loadSnapshotEmployees } from "@/lib/reports-data";
import { createClient } from "@/lib/supabase/server";
import { currentUserId } from "@/lib/auth/session";
import { withUser } from "@/lib/db";
type SearchParams = {
// Nur die Parameter, die diese Seite selbst auswertet. Die Auswahlkriterien
// stehen ebenfalls in der Adresszeile, werden aber geschlossen von
// parseCriteria gelesen — siehe lib/report-criteria.ts.
type SearchParams = Record<string, string | string[] | undefined> & {
mode?: string;
measure?: string;
group?: string;
@@ -26,16 +32,15 @@ type SearchParams = {
division?: string;
location?: string;
status?: string;
employment?: string;
asOf?: string;
eventType?: string;
eventSubtype?: string;
from?: string;
to?: string;
};
export default async function ReportsPage({ searchParams }: { searchParams: Promise<SearchParams> }) {
const params = await searchParams;
const supabase = await createClient();
const mode = parseMode(params.mode);
// Both modes are parsed up front so the data load can start before
@@ -45,44 +50,57 @@ export default async function ReportsPage({ searchParams }: { searchParams: Prom
const eventGroup = parseEventGroupDimension(params.group);
const eventSplit = parseEventSplitDimension(params.split);
const eventType = parseEventType(params.eventType);
const eventSubtype = parseEventSubtype(params.eventSubtype, eventType);
const from = parseEventDateParam(params.from);
const to = parseEventDateParam(params.to);
const measure = parseMeasure(params.measure);
const group = parseGroupDimension(params.group);
const split = parseSplitDimension(params.split);
const criteria = parseCriteria((k) => (typeof params[k] === "string" ? (params[k] as string) : undefined));
// The report data depends on neither the org lookups nor on who is signed
// in, so all three go out together. Against a hosted database a round trip
// costs about as much as the query itself, which made this page's three
// sequential waves its dominant cost.
const [{ lookups, divisions, locations }, { data: userRes }, events, employees] = await Promise.all([
loadOrgLookups(supabase),
supabase.auth.getUser(),
mode === "events"
? loadEventHistory(supabase, {
eventType: eventType ?? undefined,
division: params.division,
location: params.location,
from,
to,
})
: Promise.resolve([]),
mode === "snapshot"
? loadSnapshotEmployees(supabase, {
division: params.division,
location: params.location,
status: params.status,
employment: params.employment,
asOf,
})
: Promise.resolve([]),
]);
const userId = await currentUserId();
const user = userRes.user;
// Still a wave of its own: it needs the user id the call above resolves.
const { data: savedReports } = user
? await supabase.from("saved_reports").select("id, name, config").eq("created_by", user.id).order("created_at", { ascending: false })
: { data: [] };
// Alles in einer Transaktion — dort gilt der Sitzungskontext, und der
// Lesestand ist über alle Abfragen hinweg derselbe. Vorher waren es drei
// Wellen nacheinander, was gegen eine entfernte Datenbank der teuerste
// Teil dieser Seite war.
const { lookups, units, locations, events, employees, savedReports } = await withUser(userId, async (tx) => {
const [{ lookups, units, locations }, events, employees, savedReports] = await Promise.all([
loadOrgLookups(tx),
mode === "events"
? loadEventHistory(tx, {
eventType: eventType ?? undefined,
eventSubtype: eventSubtype ?? undefined,
division: params.division,
location: params.location,
from,
to,
})
: Promise.resolve([]),
mode === "snapshot"
? loadSnapshotEmployees(tx, {
division: params.division,
location: params.location,
status: params.status,
criteria,
asOf,
})
: Promise.resolve([]),
userId
? tx
.selectFrom("saved_reports")
.select(["id", "name", "config"])
.where("created_by", "=", userId)
.orderBy("created_at", "desc")
.execute()
: Promise.resolve([]),
]);
return { lookups, units, locations, events, employees, savedReports };
});
if (mode === "events") {
const rows = aggregateEvents(events, eventGroup, eventSplit, lookups);
@@ -94,13 +112,14 @@ export default async function ReportsPage({ searchParams }: { searchParams: Prom
eventGroup={eventGroup}
eventSplit={eventSplit ?? ""}
eventType={eventType ?? ""}
eventSubtype={eventSubtype ?? ""}
eventFilters={{ division: params.division ?? "", location: params.location ?? "", from: from ?? "", to: to ?? "" }}
rows={rows}
total={sumValues(rows)}
recordCount={events.length}
divisions={divisions}
units={units}
locations={locations}
savedReports={savedReports ?? []}
savedReports={savedReports}
/>
</Suspense>
);
@@ -120,14 +139,14 @@ export default async function ReportsPage({ searchParams }: { searchParams: Prom
division: params.division ?? "",
location: params.location ?? "",
status: params.status ?? "",
employment: params.employment ?? "",
}}
criteria={criteria}
rows={rows}
total={totalForRows(rows, measure)}
recordCount={employees.length}
divisions={divisions}
units={units}
locations={locations}
savedReports={savedReports ?? []}
savedReports={savedReports}
/>
</Suspense>
);

View File

@@ -1,14 +1,31 @@
import { login, logout } from "@/actions/auth";
import { Button } from "@/components/ui/Button";
import { CONTROL_CLASS } from "@/components/ui/Field";
import { EntraSignInButton } from "@/components/auth/EntraSignInButton";
import { PasswortFormular } from "@/components/auth/PasswortFormular";
import { AppWortmarke } from "@/components/brand/Logo";
import { logout, signInWithEntra } from "@/actions/auth";
// The query string is attacker-controlled, so the login page renders a message
// looked up by code rather than whatever text ?error= carries. Reflecting the
// raw parameter let anyone put arbitrary wording ("Ihr Konto wurde gesperrt,
// rufen Sie …") on the real, correctly-branded sign-in screen.
// rufen Sie …") on the real, correctly-branded sign-in screen. Dasselbe gilt
// für die Fehlertexte, die Entra im Rückweg mitschickt.
const ERROR_MESSAGES = {
no_hr_access: "Kein HR-Zugriff. Bitte wenden Sie sich an eine:n bestehende:n HR-Benutzer:in.",
invalid_credentials: "E-Mail oder Passwort ist falsch.",
no_hr_access: {
title: "Kein HR-Zugriff",
body: "Ihr Firmenkonto ist bekannt, aber nicht für die Personalverwaltung freigeschaltet. Bitte wenden Sie sich an eine:n bestehende:n HR-Benutzer:in.",
},
sso_failed: {
title: "Anmeldung fehlgeschlagen",
body: "Die Anmeldung über das Firmenkonto konnte nicht abgeschlossen werden. Bitte versuchen Sie es erneut.",
},
// Auth.js' eigener Code für eine gescheiterte Passwortanmeldung. Im Regelfall
// kommt er hier nicht an — die Server Action fängt den Fehlschlag ab und
// zeigt ihn am Formular. Ohne diesen Eintrag fiele er aber auf `sso_failed`
// zurück, und dort stünde „über das Firmenkonto", was mit dem tatsächlichen
// Weg nichts zu tun hätte.
CredentialsSignin: {
title: "Anmeldung fehlgeschlagen",
body: "E-Mail-Adresse oder Passwort stimmt nicht.",
},
} as const;
type ErrorCode = keyof typeof ERROR_MESSAGES;
@@ -19,60 +36,140 @@ type LoginPageProps = {
export default async function LoginPage({ searchParams }: LoginPageProps) {
const params = await searchParams;
const code = params.error && Object.hasOwn(ERROR_MESSAGES, params.error) ? (params.error as ErrorCode) : null;
// Ein unbekannter Code wird nicht verschluckt, sondern auf die allgemeine
// Meldung abgebildet: Auth.js schickt bei einem Fehlschlag seine eigenen
// Codes („Configuration", „AccessDenied", „OAuthCallbackError" …), und ohne
// diese Abbildung stünde man vor einer Anmeldeseite, die so tut, als wäre
// nichts gewesen. Angezeigt wird trotzdem nur eigener Text — der Parameter
// selbst kommt nie auf die Seite.
const code = params.error
? Object.hasOwn(ERROR_MESSAGES, params.error)
? (params.error as ErrorCode)
: "sso_failed"
: null;
const error = code ? ERROR_MESSAGES[code] : null;
return (
<div className="flex min-h-screen items-center justify-center bg-surface px-4">
<div className="w-full max-w-sm rounded border border-border bg-white p-8 shadow-sm">
<h1 className="text-xl font-extrabold text-ink">Alpenwerk HR</h1>
<p className="mt-1 text-sm text-ink-muted">Melden Sie sich mit Ihrem Firmenkonto an.</p>
// dvh statt vh: auf iOS zählt vh die Adressleiste mit, wodurch die Karte
// im ersten Moment unter dem Faltenrand sitzt.
<div className="min-h-dvh lg:grid lg:grid-cols-[1.05fr_1fr]">
<BrandPanel />
{error && (
<div role="alert" className="mt-4 rounded bg-danger-bg px-3 py-2 text-sm text-danger-text">
{error}
{code === "no_hr_access" && (
<form action={logout} className="mt-2">
<button type="submit" className="text-xs font-semibold underline hover:no-underline">
Abmelden und mit anderem Konto versuchen
</button>
</form>
)}
<main className="flex items-center justify-center px-6 py-12 lg:py-6">
<div className="w-full max-w-sm">
{/* Ohne Versatz: hier steht das Logo auf Weiss und bekommt nach §4.1
sein rosa Feld, dessen Kante mit der Ueberschrift darunter
fluchten soll. */}
<div className="lg:hidden">
<AppWortmarke hoehe={26} textKlasse="text-ink" />
</div>
)}
<form action={login} className="mt-6 flex flex-col gap-4">
<div>
<label htmlFor="email" className="mb-1 block text-sm font-semibold text-ink">
E-Mail
</label>
<input
id="email"
name="email"
type="email"
required
autoComplete="username"
className={CONTROL_CLASS}
/>
<h2 className="mt-8 text-2xl font-extrabold tracking-tight text-ink lg:mt-0">Anmelden</h2>
<p className="mt-1.5 text-sm text-ink-muted">
Der Zugang läuft über Ihr Firmenkonto. Ein eigenes Passwort gibt es nicht.
</p>
{error && (
<div role="alert" className="mt-6 rounded-md border border-danger-text/20 bg-danger-bg px-4 py-3">
<p className="text-sm font-bold text-danger-text">{error.title}</p>
<p className="mt-1 text-sm text-danger-text/90">{error.body}</p>
{code === "no_hr_access" && (
<form action={logout} className="mt-3">
<button
type="submit"
className="rounded text-xs font-semibold text-danger-text underline underline-offset-2 hover:no-underline
focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-danger-text"
>
Abmelden und mit einem anderen Konto versuchen
</button>
</form>
)}
</div>
)}
<form action={signInWithEntra} className="mt-7">
<EntraSignInButton />
</form>
{/* Der Passwortweg steht bewusst *unter* dem Firmenkonto und ohne
eigene Überschrift: er ist die Ausnahme für die Testphase, nicht
die zweite gleichwertige Möglichkeit. Wer ein Firmenkonto hat,
soll oben klicken. */}
<div className="mt-6 flex items-center gap-3" aria-hidden>
<span className="h-px flex-1 bg-border-subtle" />
<span className="text-xs font-semibold uppercase tracking-wider text-ink-muted">oder</span>
<span className="h-px flex-1 bg-border-subtle" />
</div>
<div>
<label htmlFor="password" className="mb-1 block text-sm font-semibold text-ink">
Passwort
</label>
<input
id="password"
name="password"
type="password"
required
autoComplete="current-password"
className={CONTROL_CLASS}
/>
<div className="mt-6">
<PasswortFormular />
</div>
<Button type="submit" fullWidth className="mt-2">
Anmelden
</Button>
</form>
</div>
<p className="mt-6 border-t border-border-subtle pt-5 text-xs leading-relaxed text-ink-muted">
Die Anmeldung allein erteilt keinen Zugriff. HR-Rechte vergibt die Personalabteilung — bis dahin bleiben alle
Personaldaten verschlossen.
</p>
</div>
</main>
</div>
);
}
function BrandPanel() {
return (
// Rosa und nicht Blau: Rosa ist die Farbe, in der die Marke auftritt, und
// die Flaeche ist das Groesste, was diese Seite zu vergeben hat. Blau war
// hier doppelt falsch — es drehte das Verhaeltnis der beiden Markenfarben
// um, und das Logo bringt sein eigenes rosa Feld mit (§1.2), das auf Blau
// wie ein aufgeklebtes Rechteck stand. Auf Rosa geht es in die Flaeche
// ueber, und genau das meint §3.1 mit „in einem grossflaechigen rosa
// Umfeld eingebettet".
<aside className="relative hidden overflow-hidden bg-accent-500 lg:flex lg:flex-col lg:justify-between lg:p-12">
{/* Ein feines Raster und eine leichte Tiefe zur unteren Ecke — genug
Struktur, damit die Fläche nicht wie ein Farbfehler wirkt, aber ohne
Bilddatei und ohne von der einen Schaltfläche gegenüber abzulenken.
Beides aus ink: Weiss verschwindet auf Rosa, und die Lichtblende, die
hier vorher lag, hellte die Markenfarbe so weit auf, dass sie kaum
noch die Markenfarbe war. */}
<div
aria-hidden="true"
className="pointer-events-none absolute inset-0"
style={{
backgroundImage:
"radial-gradient(45rem 45rem at 100% 100%, rgb(35 31 32 / 0.08), transparent 60%)," +
"linear-gradient(rgb(35 31 32 / 0.04) 1px, transparent 1px)," +
"linear-gradient(90deg, rgb(35 31 32 / 0.04) 1px, transparent 1px)",
backgroundSize: "auto, 3rem 3rem, 3rem 3rem",
}}
/>
{/* -ml-3 gleicht den Freiraum des Logos aus (hoehe 36 / 3 = 12 px),
damit der Schriftzug buendig mit dem Text darunter beginnt. */}
{/* Alles Geschriebene hier steht in brand-700. Weiss faellt auf Manner
Rosa mit 2.18:1 aus, und ink traegt zwar (7.47:1), sieht aber aus wie
Text, der aus Versehen auf der Marke gelandet ist. Dunkelblau auf
Rosa (6.60:1) ist dieselbe Paarung, aus der der Schriftzug selbst
besteht. Die Abstufung macht Groesse und Gewicht, nicht Transparenz:
eine aufgehellte Schrift waere genau das, was hier durchfaellt. */}
<div className="relative -ml-3">
<AppWortmarke hoehe={36} aufRosa textKlasse="text-brand-700" />
</div>
<div className="relative max-w-md">
<p className="text-3xl font-extrabold leading-tight tracking-tight text-brand-700">
Alles im Blick. Alles Manner.
</p>
<p className="mt-4 text-sm leading-relaxed text-brand-700">
Stammdaten, Planstellen und Berichtslinien der Alpenwerk Industrie GmbH — jederzeit auch zu einem beliebigen
Stichtag.
</p>
</div>
<p className="relative text-xs font-semibold text-brand-700">Interne Anwendung · Zugriff nur für die Personalabteilung</p>
</aside>
);
}
// Die vier Quadrate, die hier als Platzhalter-Bildmarke standen, sind
// entfallen: an ihrer Stelle steht jetzt das Manner-Logo
// (components/brand/Logo.tsx).

View File

@@ -0,0 +1,9 @@
import { handlers } from "@/auth";
// Der Rückweg aus Entra ID und die Endpunkte für An- und Abmeldung.
//
// Tritt an die Stelle von app/auth/callback/route.ts: den Tausch des
// Einmal-Codes gegen eine Sitzung, die Prüfung von `state` und `nonce` und
// das Setzen des Cookies macht jetzt Auth.js. Die Rückruf-Adresse in der
// Entra-Anwendungsregistrierung ändert sich dadurch — siehe docs/entra-sso.md.
export const { GET, POST } = handlers;

View File

@@ -1,25 +1,29 @@
import { NextResponse, type NextRequest } from "next/server";
import { createAdminClient } from "@/lib/supabase/admin";
import { asSystem } from "@/lib/db";
import { callFunction } from "@/lib/db/rpc";
// Applies effective-dated changes (Versetzung/Beförderung/Karenz/Reorg/Daten
// ändern with a future "Wirksam ab" date) once their date has arrived — see
// apply_due_pending_changes() in supabase/migrations. Runs as a Vercel Cron
// job (see vercel.json), not on behalf of any HR user, so it authenticates
// via a shared secret rather than a Supabase session and uses the
// service-role client (the one legitimate server-only use case for it).
// apply_due_pending_changes() in db/migrations.
//
// Gerufen wird das vom `cron`-Dienst aus docker-compose.yml, täglich um 03:00.
// Nicht im Namen einer HR-Person: es gibt keine angemeldete Sitzung, deshalb
// weist sich der Aufruf mit einem gemeinsamen Geheimnis aus (CRON_SECRET).
export async function GET(request: NextRequest) {
const authHeader = request.headers.get("authorization");
if (!process.env.CRON_SECRET || authHeader !== `Bearer ${process.env.CRON_SECRET}`) {
return NextResponse.json({ error: "Nicht autorisiert." }, { status: 401 });
}
const supabase = createAdminClient();
const { data, error } = await supabase.rpc("apply_due_pending_changes");
if (error) {
console.error("apply_due_pending_changes failed:", error);
// Kein privilegierter Zugang mehr: derselbe Datenbankbenutzer ohne
// BYPASSRLS wie überall. apply_due_pending_changes ist SECURITY DEFINER
// und prüft selbst, was sie tut — der Dienstschlüssel, der RLS aushebelte,
// ist damit entfallen.
try {
const applied = await asSystem((tx) => callFunction(tx, "apply_due_pending_changes"));
return NextResponse.json({ applied });
} catch (err) {
console.error("apply_due_pending_changes failed:", err);
return NextResponse.json({ error: "Interner Fehler." }, { status: 500 });
}
return NextResponse.json({ applied: data });
}

View File

@@ -0,0 +1,46 @@
import { NextResponse, type NextRequest } from "next/server";
import { baueCornerstoneZeile, CORNERSTONE_CSV, cornerstoneSpalten, type CornerstoneKontext } from "@/lib/cornerstone";
import { loadKontierungen } from "@/lib/cost-centers";
import { exportFilename, exportResponseHeaders, toCsv, toXlsx } from "@/lib/export";
import { exportParameter, ladeExportMitarbeiter } from "@/lib/export-auswahl";
import { todayIso } from "@/lib/format";
import { requireHrUser } from "@/lib/auth/require-hr";
import { withUser } from "@/lib/db";
// Der Export für Cornerstone — Spalten und Zuordnung stehen in
// lib/cornerstone.ts.
//
// Dieselben Personen wie im vollständigen Export daneben, mit denselben
// Filtern (lib/export-auswahl.ts). Wer nur die Aktiven einspielen will,
// stellt das auf der Berichtsseite ein, bevor er exportiert.
export async function GET(request: NextRequest) {
const gate = await requireHrUser();
if ("denied" in gate) return gate.denied;
const { format, asOf, filters } = exportParameter(request.nextUrl.searchParams);
const stichtag = asOf ?? todayIso();
const { zeilen } = await withUser(gate.userId, async (tx) => {
const { rows, managerKennung } = await ladeExportMitarbeiter(tx, { asOf, filters });
// Die eine Angabe, die die gemeinsame Auswahl nicht mitbringt: die
// Kostenstelle hängt an der Planstelle, nicht an der Person. Erst jetzt,
// weil erst jetzt feststeht, um welche Planstellen es geht.
const positionIds = [...new Set(rows.map((r) => r.position_id).filter((id): id is string => Boolean(id)))];
const kontext: CornerstoneKontext = {
managerKennung,
kostenstelle: await loadKontierungen(tx, { asOf: stichtag, positionIds }),
};
return { zeilen: rows.map((r) => baueCornerstoneZeile(r, kontext)) };
});
const filename = exportFilename("cornerstone-export", format);
// Form und Spalten kommen beide aus lib/cornerstone.ts — siehe dort.
const body =
format === "xlsx"
? await toXlsx(zeilen, cornerstoneSpalten(), "Worksheet")
: toCsv(zeilen, cornerstoneSpalten(), CORNERSTONE_CSV);
// Derselbe Umweg über Blob wie in den anderen Exporten (TS#59417).
return new NextResponse(new Blob([body as BlobPart]), { headers: exportResponseHeaders(filename, format) });
}

View File

@@ -1,55 +1,27 @@
import { NextResponse, type NextRequest } from "next/server";
import { statusLabel } from "@/lib/absence";
import { exportFilename, exportResponseHeaders, toCsv, toXlsx, type ExportColumn } from "@/lib/export";
import { deriveStatusAsOf, parseIsoDateParam, parseStatuses, type OrgLookups } from "@/lib/reports";
import { loadDependentsCounts, loadOrgLookups, type ReportFilters } from "@/lib/reports-data";
import { requireHrUser } from "@/lib/supabase/auth";
import { fetchAllRows } from "@/lib/supabase/query";
import { createClient } from "@/lib/supabase/server";
import type { Database, EmploymentType, Weekday } from "@/lib/supabase/types";
import { exportParameter, ladeExportMitarbeiter, type ExportMitarbeiter } from "@/lib/export-auswahl";
import { sortiereWochentage } from "@/lib/wochentage";
import { deriveStatusAsOf, type OrgLookups } from "@/lib/reports";
import { requireHrUser } from "@/lib/auth/require-hr";
import { withUser } from "@/lib/db";
type EmployeeRow = Database["public"]["Tables"]["employees"]["Row"];
type EmployeeRow = ExportMitarbeiter;
// Full raw data dump — every column on `employees`, not just the fields a
// pivot report groups by. Respects the same division/location/status/
// employment filters as the Berichte page. With `asOf` (Stichtag), status
// filtering happens against the *derived* status as of that date rather
// than the live `status` column — see deriveStatusAsOf.
// employment filters as the Berichte page. Wer darin steht, entscheidet
// lib/export-auswahl.ts — dieselbe Auswahl wie im Honestly-Export.
export async function GET(request: NextRequest) {
const supabase = await createClient();
const denied = await requireHrUser(supabase);
if (denied) return denied;
const gate = await requireHrUser();
if ("denied" in gate) return gate.denied;
const params = request.nextUrl.searchParams;
const format = params.get("format") === "xlsx" ? "xlsx" : "csv";
const asOf = parseIsoDateParam(params.get("asOf"));
const filters: ReportFilters = {
division: params.get("division") ?? undefined,
location: params.get("location") ?? undefined,
status: params.get("status") ?? undefined,
employment: params.get("employment") ?? undefined,
};
const { format, asOf, filters } = exportParameter(request.nextUrl.searchParams);
const { rows, lookups, managerName, dependentsCounts } = await withUser(gate.userId, (tx) =>
ladeExportMitarbeiter(tx, { asOf, filters })
);
const statuses = parseStatuses(filters.status);
function employeeQuery() {
let query = supabase.from("employees").select("*").order("last_name").order("id");
if (filters.division) query = query.eq("division_id", filters.division);
if (filters.location) query = query.eq("location_id", filters.location);
if (filters.employment) query = query.eq("employment_type", filters.employment as EmploymentType);
if (!asOf) query = query.in("status", statuses);
return query;
}
const [employees, { lookups }, allEmployees, dependentsCounts] = await Promise.all([
fetchAllRows(employeeQuery),
loadOrgLookups(supabase),
fetchAllRows(() => supabase.from("employees").select("id, first_name, last_name").order("id")),
loadDependentsCounts(supabase),
]);
const managerName = new Map(allEmployees.map((e) => [e.id, `${e.first_name} ${e.last_name}`]));
const rows = asOf ? employees.filter((e) => statuses.includes(deriveStatusAsOf(e, asOf))) : employees;
const columns = employeeExportColumns(lookups, managerName, dependentsCounts, asOf);
const filename = exportFilename("mitarbeiter-export", format);
@@ -59,8 +31,6 @@ export async function GET(request: NextRequest) {
return new NextResponse(new Blob([body as BlobPart]), { headers: exportResponseHeaders(filename, format) });
}
const WEEKDAY_ORDER: Weekday[] = ["Mo", "Di", "Mi", "Do", "Fr", "Sa", "So"];
function employeeExportColumns(
lookups: OrgLookups,
managerName: Map<string, string>,
@@ -75,34 +45,59 @@ function employeeExportColumns(
{ header: "Geburtsdatum", get: (e) => e.birth_date, kind: "date" },
{ header: "SV-Nummer", get: (e) => e.sv_nummer },
{ header: "Staatsbürgerschaft", get: (e) => e.nationality },
{ header: "Aufenthaltstitel", get: (e) => e.hat_aufenthaltstitel },
{ header: "Aufenthaltstitel bis", get: (e) => e.aufenthaltstitel_bis, kind: "date" },
{ header: "Adresse", get: (e) => e.address },
{ header: "Postleitzahl", get: (e) => e.postal_code },
{ header: "Ort", get: (e) => e.city },
{ header: "Wohnsitzland", get: (e) => e.address_country },
{ header: "E-Mail", get: (e) => e.email },
{ header: "Telefon", get: (e) => e.phone },
{ header: "Bereich", get: (e) => lookups.divisionName.get(e.division_id) ?? "" },
{ header: "Abteilung", get: (e) => (e.team_id ? (lookups.departmentNameByTeam.get(e.team_id) ?? "") : "") },
{ header: "Team", get: (e) => (e.team_id ? (lookups.teamName.get(e.team_id) ?? "") : "") },
{ header: "Private E-Mail", get: (e) => e.email },
{ header: "Firmen-E-Mail", get: (e) => e.company_email },
{ header: "Cornerstone-ID", get: (e) => e.cornerstone_id },
{ header: "Private Telefonnummer", get: (e) => e.phone },
{ header: "Bereich", get: (e) => (e.org_unit_id ? (lookups.divisionName.get(e.org_unit_id) ?? "") : "") },
{ header: "Abteilung", get: (e) => (e.org_unit_id ? (lookups.departmentName.get(e.org_unit_id) ?? "") : "") },
{ header: "Team", get: (e) => (e.org_unit_id ? (lookups.teamName.get(e.org_unit_id) ?? "") : "") },
{ header: "Standort", get: (e) => lookups.locationName.get(e.location_id) ?? "" },
{ header: "Position", get: (e) => e.job_title },
{ header: "Vorgesetzte:r", get: (e) => (e.manager_id ? (managerName.get(e.manager_id) ?? "") : "") },
{ header: "Führungskraft", get: (e) => e.is_lead },
{ header: "Org-Level", get: (e) => e.org_level },
{ header: "Planstelle", get: (e) => e.position_number },
{ header: "Leitungsplanstelle", get: (e) => e.is_chief },
{ header: "Beschäftigungsausmaß", get: (e) => e.employment_type },
{ header: "Wochenstunden", get: (e) => e.weekly_hours },
// work_days is stored in click order (see RoleEmploymentFields), not
// guaranteed chronological — re-sort Mo→So for the export.
{ header: "Arbeitstage", get: (e) => [...e.work_days].sort((a, b) => WEEKDAY_ORDER.indexOf(a as Weekday) - WEEKDAY_ORDER.indexOf(b as Weekday)).join(", ") },
// Seit lib/wochentage.ts wird sortiert gespeichert; der Bestand kann aber
// noch unsortierte Zeilen aus der Zeit davor tragen. Hier bleibt es
// deshalb stehen — im Export kostet es nichts und macht die Spalte
// unabhängig davon, wann eine Zeile zuletzt gespeichert wurde.
{ header: "Arbeitstage", get: (e) => sortiereWochentage(e.work_days).join(", ") },
{ header: "Vertragsart", get: (e) => e.contract_type },
{ header: "Befristet bis", get: (e) => e.contract_end_date, kind: "date" },
{ header: "Angestellte:r / Arbeiter:in", get: (e) => e.worker_type },
{ header: "Beschäftigtengruppe", get: (e) => e.worker_type },
{ header: "Mitarbeiterart", get: (e) => e.mitarbeiterart },
{ header: "Kollektivvertrag", get: (e) => e.collective_agreement },
{ header: "Betriebsrat", get: (e) => e.is_betriebsrat },
{ header: "Dienstwagen", get: (e) => e.has_dienstwagen },
{ header: "Antriebsart", get: (e) => e.dienstwagen_art ?? "" },
{ header: "Besonderer Kündigungsschutz", get: (e) => e.has_kuendigungsschutz },
{ header: "Personenkreis", get: (e) => e.kuendigungsschutz_grund ?? "" },
{ header: "Kündigungsschutz ab", get: (e) => e.kuendigungsschutz_ab, kind: "date" },
{ header: "Kündigungsschutz bis", get: (e) => e.kuendigungsschutz_bis, kind: "date" },
// Der Bericht, den der Workshop verlangt hat (Anforderung 5a): wer ist
// begünstigt behindert, mit wieviel Prozent, ab und bis wann. Vier
// Spalten statt einer zusammengesetzten — in Excel wird danach gefiltert
// und summiert, und ein Text wie „50% seit 2019" liesse beides nicht zu.
{ header: "Begünstigt behindert", get: (e) => e.ist_beguenstigt_behindert },
{ header: "Grad der Behinderung (%)", get: (e) => e.behinderung_grad ?? "" },
{ header: "Bescheid ab", get: (e) => e.behinderung_ab, kind: "date" },
{ header: "Bescheid bis", get: (e) => e.behinderung_bis, kind: "date" },
{ header: "Teilzeitvariante", get: (e) => e.teilzeit_art ?? "" },
{ header: "Teilzeit bis", get: (e) => e.teilzeit_bis, kind: "date" },
{ header: "Notfallkontakt", get: (e) => e.emergency_contact_name ?? "" },
{ header: "Notfallkontakt Telefon", get: (e) => e.emergency_contact_phone ?? "" },
{ header: "Notfallkontakt Verhältnis", get: (e) => e.emergency_contact_relation ?? "" },
{ header: "Laterale Führung", get: (e) => e.is_laterale_fuehrung },
{ header: "C-Level", get: (e) => e.is_c_level },
{ header: "Paygrade", get: (e) => e.paygrade },
{ header: "Hay-Grade", get: (e) => e.paygrade },
{ header: "Herkunft", get: (e) => e.source },
// The export shows the display name, not the raw enum value — a payroll
// hand-off saying "Karenz" for what the app calls Langzeitabwesenheit
@@ -112,6 +107,9 @@ function employeeExportColumns(
{ header: "Eintrittsdatum", get: (e) => e.entry_date, kind: "date" },
{ header: "Austrittsdatum", get: (e) => e.exit_date, kind: "date" },
{ header: "Austrittsgrund", get: (e) => e.exit_reason },
// Eigene Spalte neben dem Grund: aus ihm folgt sie nicht. Leer heisst
// „nicht erfasst" und nicht „weder noch".
{ header: "Freiwillig/unfreiwillig", get: (e) => e.austrittsart ?? "" },
{ header: "Abwesenheit ab", get: (e) => e.karenz_start_date, kind: "date" },
{ header: "Rückkehr geplant", get: (e) => e.karenz_return_date, kind: "date" },
{ header: "Anzahl Angehörige", get: (e) => dependentsCounts.get(e.id) ?? 0 },

View File

@@ -1,33 +1,46 @@
import { NextResponse, type NextRequest } from "next/server";
import { exportFilename, exportResponseHeaders, toCsv, toXlsx, type ExportColumn } from "@/lib/export";
import { EVENT_TYPE_LABELS, parseEventDateParam, parseEventType, type OrgLookups, type ReportEvent } from "@/lib/reports";
import {
EVENT_TYPE_LABELS,
parseEventDateParam,
parseEventSubtype,
parseEventType,
type OrgLookups,
type ReportEvent,
} from "@/lib/reports";
import { loadEventHistory, loadOrgLookups } from "@/lib/reports-data";
import { requireHrUser } from "@/lib/supabase/auth";
import { createClient } from "@/lib/supabase/server";
import { requireHrUser } from "@/lib/auth/require-hr";
import { withUser } from "@/lib/db";
// Full raw event-log dump — one row per employee_history entry in the
// selected period (default: current year), every event type unless one is
// picked, org columns resolved from each affected employee's current
// placement (see loadEventHistory).
export async function GET(request: NextRequest) {
const supabase = await createClient();
const denied = await requireHrUser(supabase);
if (denied) return denied;
const gate = await requireHrUser();
if ("denied" in gate) return gate.denied;
const params = request.nextUrl.searchParams;
const format = params.get("format") === "xlsx" ? "xlsx" : "csv";
const eventType = parseEventType(params.get("eventType"));
const [{ lookups }, events] = await Promise.all([
loadOrgLookups(supabase),
loadEventHistory(supabase, {
eventType: eventType ?? undefined,
division: params.get("division") ?? undefined,
location: params.get("location") ?? undefined,
from: parseEventDateParam(params.get("from")),
to: parseEventDateParam(params.get("to")),
}),
]);
const { lookups, events } = await withUser(gate.userId, async (tx) => {
const [{ lookups }, events] = await Promise.all([
loadOrgLookups(tx),
loadEventHistory(tx, {
eventType: eventType ?? undefined,
// Ohne diese Zeile exportierte die Schaltfläche neben der Auswertung
// etwas anderes, als auf dem Bildschirm steht — die Einschränkung auf
// die Beendigungsart fiele beim Export still weg.
eventSubtype: parseEventSubtype(params.get("eventSubtype"), eventType) ?? undefined,
division: params.get("division") ?? undefined,
location: params.get("location") ?? undefined,
from: parseEventDateParam(params.get("from")),
to: parseEventDateParam(params.get("to")),
}),
]);
return { lookups, events };
});
const columns = eventExportColumns(lookups);
const filename = exportFilename(`ereignisse-${eventType ?? "alle"}`, format);
@@ -41,12 +54,15 @@ function eventExportColumns(lookups: OrgLookups): ExportColumn<ReportEvent>[] {
return [
{ header: "Datum", get: (e) => e.event_date, kind: "date" },
{ header: "Ereignistyp", get: (e) => EVENT_TYPE_LABELS[e.event_type] ?? e.event_type },
// Beendigungsart bzw. Art der Langzeitabwesenheit. Leer bei allen
// Ereignissen, die keinen Untertyp kennen — eine Versetzung hat keinen.
{ header: "Untertyp", get: (e) => e.subtype ?? "" },
{ header: "Vorname", get: (e) => e.first_name },
{ header: "Nachname", get: (e) => e.last_name },
{ header: "Position", get: (e) => e.job_title },
{ header: "Bereich", get: (e) => lookups.divisionName.get(e.division_id) ?? "" },
{ header: "Abteilung", get: (e) => (e.team_id ? (lookups.departmentNameByTeam.get(e.team_id) ?? "") : "") },
{ header: "Team", get: (e) => (e.team_id ? (lookups.teamName.get(e.team_id) ?? "") : "") },
{ header: "Bereich", get: (e) => (e.org_unit_id ? (lookups.divisionName.get(e.org_unit_id) ?? "") : "") },
{ header: "Abteilung", get: (e) => (e.org_unit_id ? (lookups.departmentName.get(e.org_unit_id) ?? "") : "") },
{ header: "Team", get: (e) => (e.org_unit_id ? (lookups.teamName.get(e.org_unit_id) ?? "") : "") },
{ header: "Standort", get: (e) => lookups.locationName.get(e.location_id) ?? "" },
{ header: "Beschreibung", get: (e) => e.description },
];

View File

@@ -0,0 +1,29 @@
import { NextResponse, type NextRequest } from "next/server";
import { exportFilename, exportResponseHeaders, toCsv, toXlsx } from "@/lib/export";
import { exportParameter, ladeExportMitarbeiter } from "@/lib/export-auswahl";
import { baueHonestlyZeilen, honestlySpalten } from "@/lib/honestly";
import { requireHrUser } from "@/lib/auth/require-hr";
import { withUser } from "@/lib/db";
// Der Export für die Mitarbeiterbefragung bei Honestly — Spalten und feste
// Werte stehen in lib/honestly.ts.
//
// Dieselben Personen wie im vollständigen Export daneben, mit denselben
// Filtern (lib/export-auswahl.ts). Wer eine Befragung nur für einen Bereich
// oder nur für Aktive will, stellt das auf der Berichtsseite ein, bevor er
// exportiert.
export async function GET(request: NextRequest) {
const gate = await requireHrUser();
if ("denied" in gate) return gate.denied;
const { format, asOf, filters } = exportParameter(request.nextUrl.searchParams);
const { rows, lookups, orgMaps } = await withUser(gate.userId, (tx) => ladeExportMitarbeiter(tx, { asOf, filters }));
const { zeilen, tiefe } = baueHonestlyZeilen(rows, orgMaps, lookups.locationName);
const spalten = honestlySpalten(tiefe);
const filename = exportFilename("honestly-export", format);
const body = format === "xlsx" ? await toXlsx(zeilen, spalten, "Honestly") : toCsv(zeilen, spalten);
// Derselbe Umweg über Blob wie im vollständigen Export (TS#59417).
return new NextResponse(new Blob([body as BlobPart]), { headers: exportResponseHeaders(filename, format) });
}

View File

@@ -0,0 +1,45 @@
import { NextResponse, type NextRequest } from "next/server";
import { exportFilename, exportResponseHeaders, toCsv, toXlsx } from "@/lib/export";
import { exportParameter, ladeExportMitarbeiter } from "@/lib/export-auswahl";
import { baueLolyoZeile, LOLYO_CSV, lolyoSpalten } from "@/lib/lolyo";
import { requireHrUser } from "@/lib/auth/require-hr";
import { withUser } from "@/lib/db";
// Der Export für die Mitarbeiter-App LOLYO — Spalten und feste Werte stehen in
// lib/lolyo.ts.
//
// Dieselben Personen wie im vollständigen Export daneben, mit denselben Filtern
// (lib/export-auswahl.ts). Wer nur einen Bereich oder nur die Aktiven anlegen
// will, stellt das auf der Berichtsseite ein, bevor er exportiert.
/**
* Das gemeinsame Startpasswort, mit dem die Konten in LOLYO angelegt werden.
*
* Steht bewusst **hier** und nicht in lib/lolyo.ts: eine Route ist serverseitig
* und gelangt nie in ein Bündel, das der Browser lädt. Eine Konstante in einer
* lib-Datei wäre nur so lange sicher, wie niemand sie aus einem Client-Bauteil
* heraus einbindet — und das sähe man dem Bündel nicht an. Dieselbe Überlegung
* steht in lib/passwort.ts.
*
* Es ist dasselbe Passwort wie in Alpenwerk, so bestellt. Damit gilt hier auch
* dasselbe: es ist allen gemeinsam und damit bekannt, und es trägt so lange,
* bis die Person es wechselt. Die erzeugte Datei ist deshalb kein Anhang, den
* man weiterleitet.
*/
const STARTPASSWORT = "Initialpasswort2026!";
export async function GET(request: NextRequest) {
const gate = await requireHrUser();
if ("denied" in gate) return gate.denied;
const { format, asOf, filters } = exportParameter(request.nextUrl.searchParams);
const { rows } = await withUser(gate.userId, (tx) => ladeExportMitarbeiter(tx, { asOf, filters }));
const zeilen = rows.map((r) => baueLolyoZeile(r, STARTPASSWORT));
const spalten = lolyoSpalten();
const filename = exportFilename("lolyo-export", format);
const body = format === "xlsx" ? await toXlsx(zeilen, spalten, "LOLYO") : toCsv(zeilen, spalten, LOLYO_CSV);
// Derselbe Umweg über Blob wie im vollständigen Export (TS#59417).
return new NextResponse(new Blob([body as BlobPart]), { headers: exportResponseHeaders(filename, format) });
}

View File

@@ -1,5 +1,6 @@
import { NextResponse, type NextRequest } from "next/server";
import { exportFilename, exportResponseHeaders, toCsv, toXlsx, type ExportColumn } from "@/lib/export";
import { parseCriteria } from "@/lib/report-criteria";
import {
aggregateEvents,
aggregateReport,
@@ -24,59 +25,64 @@ import {
type ReportRow,
} from "@/lib/reports";
import { loadEventHistory, loadOrgLookups, loadSnapshotEmployees } from "@/lib/reports-data";
import { requireHrUser } from "@/lib/supabase/auth";
import { createClient } from "@/lib/supabase/server";
import { requireHrUser } from "@/lib/auth/require-hr";
import { withUser } from "@/lib/db";
// Exports exactly the pivot table currently on screen (same mode/measure or
// event-type/group/split/filters, read from the query string the client
// already keeps in the URL) as a flat table — one row per group, one column
// per split value if a split is active.
export async function GET(request: NextRequest) {
const supabase = await createClient();
const denied = await requireHrUser(supabase);
if (denied) return denied;
const gate = await requireHrUser();
if ("denied" in gate) return gate.denied;
const params = request.nextUrl.searchParams;
const format = params.get("format") === "xlsx" ? "xlsx" : "csv";
const mode = parseMode(params.get("mode"));
const { lookups } = await loadOrgLookups(supabase);
// Eine Transaktion für Nachschlagewerte und Daten: dort gilt der
// Sitzungskontext, und beide sehen denselben Lesestand.
const { rows, columns, filenameBase } = await withUser(gate.userId, async (tx) => {
const { lookups } = await loadOrgLookups(tx);
let rows: ReportRow[];
let columns: ExportColumn<ReportRow>[];
let filenameBase: string;
let rows: ReportRow[];
let columns: ExportColumn<ReportRow>[];
let filenameBase: string;
if (mode === "events") {
const group = parseEventGroupDimension(params.get("group"));
const split = parseEventSplitDimension(params.get("split"));
const eventType = parseEventType(params.get("eventType"));
const events = await loadEventHistory(tx, {
eventType: eventType ?? undefined,
division: params.get("division") ?? undefined,
location: params.get("location") ?? undefined,
from: parseEventDateParam(params.get("from")),
to: parseEventDateParam(params.get("to")),
});
rows = aggregateEvents(events, group, split, lookups);
columns = eventReportColumns(rows, group, split, sumValues(rows));
filenameBase = `ereignisse-${eventType ?? "alle"}-${group}`;
} else {
const measure = parseMeasure(params.get("measure"));
const group = parseGroupDimension(params.get("group"));
const split = parseSplitDimension(params.get("split"));
const asOf = parseIsoDateParam(params.get("asOf"));
const employees = await loadSnapshotEmployees(tx, {
division: params.get("division") ?? undefined,
location: params.get("location") ?? undefined,
status: params.get("status") ?? undefined,
criteria: parseCriteria((k) => params.get(k)),
asOf,
});
rows = aggregateReport(employees, measure, group, split, lookups, asOf);
columns = snapshotReportColumns(rows, measure, group, split, totalForRows(rows, measure));
filenameBase = `bericht-${measure}-${group}`;
}
if (mode === "events") {
const group = parseEventGroupDimension(params.get("group"));
const split = parseEventSplitDimension(params.get("split"));
const eventType = parseEventType(params.get("eventType"));
const events = await loadEventHistory(supabase, {
eventType: eventType ?? undefined,
division: params.get("division") ?? undefined,
location: params.get("location") ?? undefined,
from: parseEventDateParam(params.get("from")),
to: parseEventDateParam(params.get("to")),
});
rows = aggregateEvents(events, group, split, lookups);
columns = eventReportColumns(rows, group, split, sumValues(rows));
filenameBase = `ereignisse-${eventType ?? "alle"}-${group}`;
} else {
const measure = parseMeasure(params.get("measure"));
const group = parseGroupDimension(params.get("group"));
const split = parseSplitDimension(params.get("split"));
const asOf = parseIsoDateParam(params.get("asOf"));
const employees = await loadSnapshotEmployees(supabase, {
division: params.get("division") ?? undefined,
location: params.get("location") ?? undefined,
status: params.get("status") ?? undefined,
employment: params.get("employment") ?? undefined,
asOf,
});
rows = aggregateReport(employees, measure, group, split, lookups, asOf);
columns = snapshotReportColumns(rows, measure, group, split, totalForRows(rows, measure));
filenameBase = `bericht-${measure}-${group}`;
}
return { rows, columns, filenameBase };
});
const filename = exportFilename(filenameBase, format);
const body = format === "xlsx" ? await toXlsx(rows, columns, "Bericht") : toCsv(rows, columns);
// TS 5.9's Uint8Array<ArrayBufferLike> vs DOM's BlobPart/ArrayBuffer<> generic
// mismatch (microsoft/TypeScript#59417) — a real Uint8Array works fine here.

135
app/api/import/route.ts Normal file
View File

@@ -0,0 +1,135 @@
import { NextResponse, type NextRequest } from "next/server";
import { requireHrUser } from "@/lib/auth/require-hr";
import { withUser } from "@/lib/db";
import { bestandLaden, laden, type Ladebericht } from "@/lib/import/load";
import { dateiLesen, type ImportSheet } from "@/lib/import/parse";
import { pruefe, type Befund } from "@/lib/import/validate";
// Massenimport — Prüflauf und Übernahme über denselben Weg.
//
// Es gibt bewusst **keinen** Zwischenspeicher zwischen beiden Schritten. Die
// Oberfläche schickt die Datei zweimal: einmal mit `pruefen=1`, um den
// Bericht zu zeigen, und nach der Bestätigung noch einmal zum Übernehmen.
// Das kostet eine Übertragung und erspart serverseitigen Zustand, der
// ablaufen, vollaufen oder zwischen zwei Personen verwechselt werden kann.
//
// Beide Läufe sehen denselben Bestand, weil Prüfung und Schreiben in
// derselben Transaktion stattfinden. Zwischen „geprüft" und „geschrieben"
// passt sonst eine fremde Änderung — etwa jemand, der dieselbe Planstelle
// besetzt.
/** Bricht die Transaktion ab, ohne einen Fehler zu sein. */
class Rueckabwicklung extends Error {
constructor(readonly nutzlast: unknown) {
super("Prüflauf");
}
}
// Im eigenen Container wirkt diese Angabe nicht — sie richtet sich an
// serverlose Plattformen, die einen Aufruf nach Ablauf abschneiden. Sie bleibt
// als Absichtserklärung stehen: ein Import, der länger als eine Minute
// braucht, ist einer, der in Teilen laufen sollte.
export const maxDuration = 60;
type Antwort = {
ok: boolean;
geprueft: boolean;
blaetter: string[];
fehler: Befund[];
hinweise: Befund[];
anzahl: Record<string, number>;
bericht?: Ladebericht;
meldung?: string;
};
export async function POST(request: NextRequest) {
const gate = await requireHrUser();
if ("denied" in gate) return gate.denied;
const form = await request.formData();
const nurPruefen = form.get("pruefen") === "1";
const dateien = form.getAll("datei").filter((f): f is File => f instanceof File);
if (dateien.length === 0) {
return NextResponse.json({ ok: false, meldung: "Keine Datei erhalten." }, { status: 400 });
}
// Mehrere Dateien werden zusammengesetzt: eine Mappe mit allen Blättern
// oder eine CSV je Blatt sind derselbe Vorgang.
const blaetter: ImportSheet[] = [];
const lesefehler: string[] = [];
for (const datei of dateien) {
const ergebnis = await dateiLesen(datei.name, await datei.arrayBuffer());
blaetter.push(...ergebnis.blaetter);
lesefehler.push(...ergebnis.fehler);
}
if (lesefehler.length > 0) {
return NextResponse.json(
{
ok: false,
geprueft: true,
blaetter: blaetter.map((b) => b.name),
fehler: lesefehler.map((m) => ({ blatt: "Datei", zeile: null, spalte: null, meldung: m })),
hinweise: [],
anzahl: {},
} satisfies Antwort,
{ status: 422 }
);
}
const profil = await withUser(gate.userId, (tx) =>
tx.selectFrom("profiles").select(["full_name", "email"]).where("id", "=", gate.userId).executeTakeFirst()
);
try {
const antwort = await withUser(gate.userId, async (tx) => {
const bestand = await bestandLaden(tx);
const geprueft = pruefe(blaetter, bestand);
const basis: Antwort = {
ok: geprueft.fehler.length === 0,
geprueft: true,
blaetter: blaetter.map((b) => b.name),
fehler: geprueft.fehler,
hinweise: geprueft.hinweise,
anzahl: geprueft.anzahl,
};
// Fehler oder Prüflauf: die Transaktion wird zurückgerollt. Beim
// Prüflauf hat sie trotzdem echte Abfragen gemacht — der Bericht
// beruht also auf dem tatsächlichen Bestand, nicht auf einer Kopie.
if (!basis.ok || nurPruefen) throw new Rueckabwicklung({ ...basis, geprueft: nurPruefen || !basis.ok });
const bericht = await laden(tx, geprueft.datensatz, bestand, {
userId: gate.userId,
name: profil?.full_name || profil?.email || "Unbekannt",
});
return { ...basis, geprueft: false, bericht };
});
return NextResponse.json(antwort);
} catch (err) {
if (err instanceof Rueckabwicklung) {
const nutzlast = err.nutzlast as Antwort;
return NextResponse.json(nutzlast, { status: nutzlast.ok ? 200 : 422 });
}
// Ein echter Fehler beim Schreiben. Die Transaktion ist zurückgerollt,
// es steht also nichts Halbes in der Datenbank.
return NextResponse.json(
{
ok: false,
geprueft: false,
blaetter: blaetter.map((b) => b.name),
fehler: [],
hinweise: [],
anzahl: {},
meldung:
err instanceof Error
? `Der Import wurde vollständig zurückgenommen. Grund: ${err.message}`
: "Der Import wurde vollständig zurückgenommen.",
} satisfies Antwort,
{ status: 500 }
);
}
}

View File

@@ -0,0 +1,96 @@
import ExcelJS from "exceljs";
import { NextResponse } from "next/server";
import { requireHrUser } from "@/lib/auth/require-hr";
import { exportFilename, exportResponseHeaders } from "@/lib/export";
import { BLAETTER } from "@/lib/import/schema";
// Die Vorlage entsteht aus demselben Schema wie die Prüfung.
//
// Das ist der Punkt: eine von Hand gepflegte Beispieldatei läuft dem Code
// hinterher, und dann verlangt die Vorlage eine Spalte, die es nicht mehr
// gibt — oder umgekehrt. Hier kann das nicht passieren; kommt in schema.ts
// eine Spalte dazu, steht sie beim nächsten Herunterladen drin.
export async function GET() {
const gate = await requireHrUser();
if ("denied" in gate) return gate.denied;
const mappe = new ExcelJS.Workbook();
mappe.creator = "Alpenwerk HR";
mappe.created = new Date();
const hinweise = mappe.addWorksheet("Hinweise");
hinweise.columns = [
{ header: "Blatt", width: 16 },
{ header: "Spalte", width: 26 },
{ header: "Pflicht", width: 9 },
{ header: "Format", width: 30 },
{ header: "Hinweis", width: 70 },
];
hinweise.getRow(1).font = { bold: true };
const formatText = (typ: (typeof BLAETTER)[number]["spalten"][number]["typ"]): string => {
switch (typ.art) {
case "datum":
return "Datum (31.12.2026)";
case "zahl":
return "Zahl (38,5)";
case "ganzzahl":
return "Ganze Zahl";
case "janein":
return "ja / nein";
case "liste":
return typ.werte ? `Mehrere mit Semikolon aus: ${typ.werte.join(", ")}` : "Mehrere mit Semikolon";
case "auswahl":
return typ.werte.join(" | ");
default:
return "Text";
}
};
for (const schema of BLAETTER) {
hinweise.addRow([schema.name, "", "", "", schema.zweck]).font = { bold: true };
for (const s of schema.spalten) {
hinweise.addRow([schema.name, s.name, s.pflicht ? "ja" : "", formatText(s.typ), s.hinweis]);
}
hinweise.addRow([]);
}
for (const schema of BLAETTER) {
const blatt = mappe.addWorksheet(schema.name);
blatt.columns = schema.spalten.map((s) => ({
header: s.name,
width: Math.max(12, Math.min(28, s.name.length + 4)),
}));
const kopf = blatt.getRow(1);
kopf.font = { bold: true };
kopf.eachCell((zelle, i) => {
const spalte = schema.spalten[i - 1];
if (!spalte) return;
// Pflichtspalten sichtbar markieren — sonst ist die erste Rückmeldung
// eine Fehlerliste statt eines Hinweises beim Ausfüllen.
if (spalte.pflicht) {
zelle.fill = { type: "pattern", pattern: "solid", fgColor: { argb: "FFFDE7EF" } };
}
const teile = [spalte.pflicht ? "Pflichtfeld." : "Optional.", formatText(spalte.typ), spalte.hinweis].filter(Boolean);
zelle.note = teile.join("\n");
});
// Eine Beispielzeile. Alles als Text, damit Excel nicht selbst
// interpretiert — der Leser deutet die Werte ohnehin.
const beispiel = schema.spalten.map((s) => s.beispiel);
if (beispiel.some(Boolean)) {
const zeile = blatt.addRow(beispiel);
zeile.font = { italic: true, color: { argb: "FF8A8A8A" } };
zeile.eachCell((z) => {
z.numFmt = "@";
});
}
blatt.views = [{ state: "frozen", ySplit: 1 }];
}
const puffer = await mappe.xlsx.writeBuffer();
const dateiname = exportFilename("import-vorlage", "xlsx");
return new NextResponse(new Blob([puffer as BlobPart]), { headers: exportResponseHeaders(dateiname, "xlsx") });
}

BIN
app/apple-icon.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 8.0 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 25 KiB

After

Width:  |  Height:  |  Size: 5.4 KiB

View File

@@ -6,6 +6,12 @@ import { useEffect } from "react";
// (app)/error.tsx is not mounted yet. It replaces <html>, so it cannot use
// the app's fonts, Tailwind layer or shared components — hence the inline
// styles. Kept deliberately plain; anything clever here can fail too.
//
// Die Farben sind dieselben wie in app/globals.css, nur von Hand: surface,
// border, ink, ink-body, ink-muted und brand-500. Sie stehen hier doppelt,
// weil diese Seite gerade dann erscheint, wenn das Stylesheet nicht
// getragen hat — eine Variable waere hier genau das, worauf man sich nicht
// verlassen kann.
export default function GlobalError({ error, reset }: { error: Error & { digest?: string }; reset: () => void }) {
useEffect(() => {
console.error("Global error:", error);
@@ -13,19 +19,19 @@ export default function GlobalError({ error, reset }: { error: Error & { digest?
return (
<html lang="de-AT">
<body style={{ margin: 0, backgroundColor: "#f9f1f5", fontFamily: "system-ui, sans-serif", color: "#2d1c26" }}>
<div style={{ maxWidth: 480, margin: "15vh auto", padding: 24, background: "#fff", border: "1px solid #eedde6", borderRadius: 8 }}>
<body style={{ margin: 0, backgroundColor: "#fdf6f4", fontFamily: "system-ui, sans-serif", color: "#231f20" }}>
<div style={{ maxWidth: 480, margin: "15vh auto", padding: 24, background: "#fff", border: "1px solid #f0dbd4", borderRadius: 8 }}>
<h1 style={{ fontSize: 18, margin: "0 0 8px" }}>Die Anwendung konnte nicht geladen werden</h1>
<p style={{ fontSize: 14, lineHeight: 1.5, color: "#503b47", margin: "0 0 16px" }}>
<p style={{ fontSize: 14, lineHeight: 1.5, color: "#4b4446", margin: "0 0 16px" }}>
Es ist ein unerwarteter Fehler aufgetreten. Ihre Daten sind davon nicht betroffen.
</p>
{error.digest && (
<p style={{ fontSize: 12, fontFamily: "monospace", color: "#7a636f", margin: "0 0 16px" }}>Fehlerkennung: {error.digest}</p>
<p style={{ fontSize: 12, fontFamily: "monospace", color: "#756c6e", margin: "0 0 16px" }}>Fehlerkennung: {error.digest}</p>
)}
<button
onClick={reset}
style={{
background: "#d6046e",
background: "#164194",
color: "#fff",
border: "none",
borderRadius: 4,

View File

@@ -1,23 +1,74 @@
@import "tailwindcss";
/* Design tokens from spec §7 (ported from tailwind.config.ts for Tailwind v4) */
/* ═══ Farben nach dem Manner CD Manual 2022 ═══════════════════════════
§1.1 kennt genau zwei Markenfarben:
Manner Rosa #F69686 CMYK 0/50/40/0 sRGB 246 150 134
Manner Blau #164194 CMYK 100/80/0/0 sRGB 22 65 148 (Reflex Blue)
Beide behalten ihren Wert unveraendert; die Abstufungen daneben sind
Aufhellungen und Abdunklungen davon, weil eine Oberflaeche Zwischentoene
fuer Hover, Chips und Flaechen braucht und das Manual nur fuer den Druck
geschrieben ist.
── Warum Blau die Interaktion traegt und Rosa die Flaeche ──
Nachgerechnet nach WCAG 2.1:
Weiss auf Rosa 2.18:1 faellt durch, auch fuer Grossschrift
Schwarz auf Rosa 7.47:1 AAA
Weiss auf Blau 9.47:1 AAA
Blau auf Weiss 9.47:1 AAA
Rosa kann also keine Schrift tragen — weder weisse noch, bei 4.34:1,
blaue Fliesschrift. Es ist eine Flaeche, auf der Dunkles steht. Blau
traegt in beide Richtungen und wird damit zur Farbe von Knopf, Link und
Fokusring. Das ist keine Auslegung des Manuals, sondern das, was die
beiden Farben physikalisch hergeben. */
@theme {
--color-brand-50: #fdf3f8;
--color-brand-100: #fdeaf3;
--color-brand-200: #f6cfe2;
--color-brand-500: #d6046e;
--color-brand-600: #b0035a;
--color-brand-700: #a30354;
/* ── Blau: alles, was man anfassen kann ── */
--color-brand-50: #eef3fb;
--color-brand-100: #dae4f5;
--color-brand-200: #afc3e6;
--color-brand-500: #164194; /* Manner Blau, CD §1.1 */
--color-brand-600: #11326f;
--color-brand-700: #0d2857;
--color-surface: #f9f1f5;
/* ── Rosa: alles, was die Marke traegt ──
accent-500 ist der Markenwert und bleibt Flaeche. Die Schrift darauf
ist ink (7.47:1), nie Weiss. */
--color-accent-50: #fef5f2;
--color-accent-100: #fde7e1;
--color-accent-200: #facec2;
--color-accent-500: #f69686; /* Manner Rosa, CD §1.1 */
--color-accent-600: #d9604b;
--color-accent-700: #a8402e;
--color-border: #eedde6;
--color-border-subtle: #f7e8ef;
--color-surface: #fdf6f4;
--color-ink: #2d1c26;
--color-ink-body: #503b47;
--color-ink-muted: #7a636f;
--color-border: #f0dbd4;
--color-border-subtle: #f8ece8;
/* Fuer die Umrandung von Eingabefeldern. Der dekorative Kartenrahmen
darueber darf blass sein; die Grenze eines Bedienelements muss nach
WCAG 1.4.11 3:1 erreichen, und das tut dieser Ton mit 3.56:1 gegen
Weiss und 3.34:1 gegen die Seitenflaeche. */
--color-border-strong: #a67f70;
/* Das Schwarz aus dem Manual selbst (#231F20), nicht reines Schwarz. */
--color-ink: #231f20;
--color-ink-body: #4b4446;
--color-ink-muted: #756c6e;
/* ── Funktionsfarben ──
Sie bleiben, was sie sind. Das Manual regelt die Identitaet, nicht die
Rueckmeldung: Rot heisst Fehler, weil die Benutzerin das mitbringt,
nicht weil es jemand entworfen hat. In einem System, in dem ein Knopf
einen Austritt erfasst, waere eine markenkonforme Fehlerfarbe kein
Stil, sondern ein Mangel.
`info` bleibt bewusst tuerkis statt blau zu werden: Blau heisst ab
jetzt „hier kann man klicken", und ein Hinweischip in derselben Farbe
saehe bedienbar aus. Gemessen kommt dazu, dass ein blaues info dem
violetten Chip zu nahe kaeme (dE 6.8 — nicht unterscheidbar). */
--color-success-bg: #dff6dd;
--color-success-text: #0e700e;
@@ -31,8 +82,11 @@
--color-info-bg: #d7f0f0;
--color-info-text: #00666d;
--color-purple-bg: #f0ecf7;
--color-purple-text: #5c2e91;
/* Nachgezogen: gegen den alten Wert #f0ecf7 stand der Fehler-Chip bei
dE 8.0 — „Austritt" und „Befoerderung" waren im Vorbeigehen dieselbe
blasse Flaeche. Jetzt dE 15.0 bei 7.9:1 Kontrast. */
--color-purple-bg: #e4d9f5;
--color-purple-text: #54277f;
/* A bare `--radius` in Tailwind v4 collapses the whole scale onto one
value — `rounded` and `rounded-lg` both came out at 8px, so a chip, an
@@ -46,12 +100,17 @@
/* Warm, brand-tinted rather than neutral grey: a pure black shadow over
the pink surface reads as dirt. Kept shallow — this is a data-dense
admin UI, the depth only has to separate a card from the page. */
--shadow-card: 0 1px 2px rgb(107 33 71 / 0.04), 0 1px 3px rgb(107 33 71 / 0.06);
--shadow-card-hover: 0 2px 4px rgb(107 33 71 / 0.06), 0 4px 12px rgb(107 33 71 / 0.08);
--shadow-overlay: 0 8px 32px rgb(45 28 38 / 0.16);
admin UI, the depth only has to separate a card from the page.
Der Grundton folgt dem Rosa der Flaeche, nicht mehr dem alten Magenta. */
--shadow-card: 0 1px 2px rgb(122 60 45 / 0.05), 0 1px 3px rgb(122 60 45 / 0.07);
--shadow-card-hover: 0 2px 4px rgb(122 60 45 / 0.07), 0 4px 12px rgb(122 60 45 / 0.09);
--shadow-overlay: 0 8px 32px rgb(35 31 32 / 0.18);
--font-sans: var(--font-nunito), system-ui, sans-serif;
/* Siehe app/layout.tsx: DIN waere die Schrift des Manuals, ist aber nicht
als Webfont lizenziert; geladen wird Barlow als naechstliegender freier
Ersatz. Die Ersatzkette bleibt neutral — faellt der Webfont aus, soll
keine gerundete Systemschrift einspringen. */
--font-sans: var(--font-din), "Segoe UI", system-ui, sans-serif;
}
body {

315
app/icon.svg Normal file

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 73 KiB

View File

@@ -1,11 +1,33 @@
import type { Metadata, Viewport } from "next";
import { Nunito } from "next/font/google";
import { Barlow } from "next/font/google";
import { ToastProvider } from "@/components/ui/Toast";
import "./globals.css";
const nunito = Nunito({
variable: "--font-nunito",
subsets: ["latin"],
// ═══ Die Schrift ═══
//
// Das CD Manual ist selbst in DIN gesetzt: nachgezaehlt tragen DIN-Regular
// 79 % und DIN-Bold 16 % des Textes, zusammen 95 %. Helvetica Neue taucht nur
// in den Visitenkarten-Mustern und im Claim auf.
//
// DIN laesst sich hier trotzdem nicht einsetzen: FF DIN und DIN Next sind
// lizenzpflichtig, und eine Druck-Lizenz deckt die Auslieferung als Webfont
// nicht ab — das ist eine eigene, nach Domain oder Abrufen bemessene Lizenz.
// Die freien Nachbauten der DIN 1451 sind Schilderschriften: enge Punzen,
// wenige Schnitte, und bei 14 px in einer Tabelle mit achthundert Zeilen
// schlechter lesbar als das, was sie ersetzen sollen.
//
// Barlow ist die naechstliegende freie Schrift mit UI-Tauglichkeit: dieselbe
// Grotesk-Familie, schmale Proportionen, geringer Strichkontrast, gerade
// Abschluesse — und neun Schnitte mit vollem Latin-Extended, also allen
// Umlauten.
//
// Die Variable heisst nach der Absicht und nicht nach dem Ersatz: liegt
// eines Tages eine Web-Lizenz fuer DIN vor, ist der Wechsel diese eine
// Deklaration und sonst nichts.
const din = Barlow({
variable: "--font-din",
// latin-ext wegen der Umlaute und des scharfen S, die in Namen vorkommen.
subsets: ["latin", "latin-ext"],
weight: ["400", "600", "700", "800"],
});
@@ -15,6 +37,11 @@ export const metadata: Metadata = {
// Added to the home screen on iOS this opens without Safari's chrome and
// keeps the app's own name rather than the page title.
appleWebApp: { capable: true, title: "Alpenwerk HR", statusBarStyle: "default" },
// app/favicon.ico, app/icon.svg und app/apple-icon.png findet Next von
// selbst; die Datei-Konventionen brauchen keinen Eintrag hier. Der Verweis
// auf das Manifest dagegen schon — app/manifest.webmanifest wird sonst
// zwar ausgeliefert, aber von keiner Seite genannt.
manifest: "/manifest.webmanifest",
};
export const viewport: Viewport = {
@@ -23,7 +50,9 @@ export const viewport: Viewport = {
// The layout extends under the notch and home indicator; every edge that
// matters pads itself back out with env(safe-area-inset-*).
viewportFit: "cover",
themeColor: "#ffffff",
// Manner Rosa (CD §1.1): die Farbe, in der mobile Browser ihre eigene
// Leiste ueber der Seite einfaerben. Weiss war hier nur die Vorgabe.
themeColor: "#F69686",
};
export default function RootLayout({
@@ -32,7 +61,7 @@ export default function RootLayout({
children: React.ReactNode;
}>) {
return (
<html lang="de-AT" className={`${nunito.variable} h-full antialiased`}>
<html lang="de-AT" className={`${din.variable} h-full antialiased`}>
<body className="flex min-h-dvh flex-col font-sans">
<ToastProvider>{children}</ToastProvider>
</body>

29
app/manifest.webmanifest Normal file
View File

@@ -0,0 +1,29 @@
{
"name": "Alpenwerk HR",
"short_name": "Alpenwerk HR",
"description": "Interne HR-Stammdatenverwaltung",
"icons": [
{
"src": "/brand/icon-192.png",
"sizes": "192x192",
"type": "image/png",
"purpose": "any"
},
{
"src": "/brand/icon-512.png",
"sizes": "512x512",
"type": "image/png",
"purpose": "any"
},
{
"src": "/brand/icon-512-maskable.png",
"sizes": "512x512",
"type": "image/png",
"purpose": "maskable"
}
],
"theme_color": "#F69686",
"background_color": "#FDF6F4",
"display": "standalone",
"start_url": "/"
}

View File

@@ -0,0 +1,57 @@
import { redirect } from "next/navigation";
import { PasswortAendernFormular } from "@/components/auth/PasswortAendernFormular";
import { CARD_CLASS } from "@/components/ui/Card";
import { currentUserId } from "@/lib/auth/session";
import { sql, withUser } from "@/lib/db";
// Diese Seite liegt **ausserhalb** der Gruppe (app), und das ist der Punkt.
//
// app/(app)/layout.tsx lässt nur durch, wer aktive HR-Person ist — und genau
// das ist man nicht, solange ein Passwortwechsel aussteht: is_hr_user() liefert
// dann false (Migration 20260908120000). Läge diese Seite unter (app), wäre sie
// für die einzigen Menschen gesperrt, die sie brauchen.
//
// Angemeldet sein muss man trotzdem: darum kümmert sich proxy.ts, der jede
// Adresse ausser /login und /api/auth hinter eine Sitzung stellt. Die Prüfung
// unten ist die zweite Linie für den Fall, dass jemand den Matcher ändert.
export const metadata = { title: "Passwort ändern" };
export default async function PasswortAendernPage() {
const userId = await currentUserId();
if (!userId) redirect("/login");
// Erzwungen oder freiwillig — davon hängt nur die Beschriftung ab und ob es
// einen Weg zurück gibt.
//
// Ob dieses Konto überhaupt ein Passwort hat, wird hier *nicht* gefragt:
// app_passwoerter ist für die Anwendungsrolle unerreichbar (Policy
// `using (false)`), und eine Auskunftsfunktion nur für diese Anzeige wäre
// eine Funktion zu viel. Wer kein Passwort hat, bekommt beim Absenden die
// Meldung aus app_passwort_aendern().
const erzwungen = await withUser(userId, async (tx) => {
const ergebnis = await sql<{ wechseln: boolean }>`select app_muss_passwort_wechseln() as wechseln`.execute(tx);
return ergebnis.rows[0]?.wechseln === true;
});
return (
<main className="flex min-h-dvh items-center justify-center px-6 py-12">
<div className="w-full max-w-sm">
<h1 className="text-2xl font-extrabold tracking-tight text-ink">Passwort ändern</h1>
{erzwungen ? (
<p className="mt-1.5 text-sm text-ink-muted">
Ihr Zugang wurde mit einem gemeinsamen Startpasswort eingerichtet. Solange es gilt, bleiben alle
Personaldaten verschlossen — bitte vergeben Sie jetzt ein eigenes.
</p>
) : (
<p className="mt-1.5 text-sm text-ink-muted">Sie können hier jederzeit ein neues Passwort vergeben.</p>
)}
<div className={`mt-7 p-5 ${CARD_CLASS}`}>
<PasswortAendernFormular erzwungen={erzwungen} />
</div>
</div>
</main>
);
}

134
auth.ts Normal file
View File

@@ -0,0 +1,134 @@
import "server-only";
import NextAuth from "next-auth";
import Credentials from "next-auth/providers/credentials";
import { authConfig } from "@/lib/auth/config";
import { asSystem, sql } from "@/lib/db";
// Die vollständige Anmeldung — die Fassung, die die Datenbank kennt.
//
// Aufgeteilt ist sie, weil proxy.ts nur den Teil aus lib/auth/config.ts lädt.
// Hier kommt das dazu, was einmal pro Anmeldung passieren muss: aus der
// Kennung, die Entra ausstellt, eine Kennung machen, die diese Anwendung
// versteht.
//
// Seit 08.09.2026 steht daneben ein zweiter Weg: Anmeldung mit Passwort, für
// die Testphase und mit eingebautem Ende (siehe Migration 20260908120000).
// Auch er gehört **hierher** und nicht nach lib/auth/config.ts, denn auch er
// spricht mit der Datenbank. Der Proxy sieht ihn nicht und braucht ihn nicht:
// er liest nur das Sitzungscookie, und das ist ein signiertes Token, dessen
// Entschlüsselung von der Anbieterliste unabhängig ist. Welcher Weg zur
// Sitzung geführt hat, steht darin nicht — und muss es auch nicht.
/**
* Legt die app_users-Zeile an oder frischt sie auf und liefert die Kennung,
* die überall sonst als `userId` durchgereicht wird.
*
* Die Datenbankfunktion ist SECURITY DEFINER und darf genau dieses eine:
* app_users schreiben. Für den einen Schreibvorgang, für den es noch keinen
* Sitzungskontext geben kann, ist das der kleinstmögliche Hebel — früher lag
* hier ein Dienstschlüssel, der jede Zeile jeder Tabelle lesen konnte.
*/
async function upsertAppUser(externalId: string, email: string, fullName: string | null): Promise<string> {
const row = await asSystem(async (tx) => {
const result = await sql<{ id: string }>`
select app_upsert_user(${externalId}, ${email}, ${fullName}) as id
`.execute(tx);
return result.rows[0];
});
if (!row?.id) throw new Error("app_upsert_user() lieferte keine Kennung.");
return row.id;
}
/**
* Anmeldung mit Passwort.
*
* Die Prüfung selbst steht vollständig in app_passwort_pruefen(): Sperre nach
* fünf Fehlversuchen, Frist für das Initialpasswort, Enddatum des
* Passwortpfads, Protokolleintrag. Hier bleibt nur das Weiterreichen — und
* das ist Absicht. Eine zweite Fassung der Regeln im Anwendungscode wäre die
* Fassung, die zuerst veraltet, und sie liesse sich umgehen, indem jemand die
* Datenbankfunktion direkt aufruft.
*
* Die Funktion liefert eine Kennung oder null und **nie einen Grund**. Was
* hier ankommt, reicht deshalb nicht aus, um zu unterscheiden, ob die Adresse
* unbekannt, das Passwort falsch oder das Konto gesperrt war. Genau so soll
* die Anmeldemaske antworten.
*/
const passwortAnbieter = Credentials({
id: "passwort",
name: "Passwort",
credentials: {
email: { label: "E-Mail", type: "email" },
passwort: { label: "Passwort", type: "password" },
},
async authorize(eingabe) {
const email = typeof eingabe?.email === "string" ? eingabe.email : "";
const passwort = typeof eingabe?.passwort === "string" ? eingabe.passwort : "";
if (!email || !passwort) return null;
// asSystem, weil es noch keine angemeldete Person gibt — die entsteht ja
// erst aus dem Ergebnis. Dieselbe Rolle ohne BYPASSRLS wie überall; die
// Funktion ist SECURITY DEFINER und darf genau das eine.
const zeile = await asSystem(async (tx) => {
const ergebnis = await sql<{ id: string | null }>`
select app_passwort_pruefen(${email}, ${passwort}) as id
`.execute(tx);
return ergebnis.rows[0];
});
if (!zeile?.id) return null;
return { id: zeile.id, email, name: null };
},
});
export const { handlers, auth, signIn, signOut } = NextAuth(() => {
const base = authConfig();
return {
...base,
// Entra bleibt der erste Eintrag und damit der Hauptweg. Die Basisliste
// wird ergänzt, nicht ersetzt: `providers: [passwortAnbieter]` hätte die
// Firmenanmeldung stillschweigend entfernt.
providers: [...base.providers, passwortAnbieter],
callbacks: {
// Die Rückrufe aus der Basis **behalten**, nicht ersetzen: dort liegt
// session(), das die Kennung aus dem Token auf die Sitzung legt. Ein
// schlichtes `callbacks: { jwt }` hätte es stillschweigend entfernt.
...base.callbacks,
async jwt({ token, profile, user }) {
// Drei Fälle, und die Reihenfolge trägt sie:
//
// 1. Entra, erster Durchlauf → `profile` liegt vor (und `user` auch)
// 2. Passwort, erster Durchlauf → nur `user`, aus authorize()
// 3. jeder weitere Aufruf → keins von beiden, Token durchreichen
//
// Deshalb wird `profile` zuerst geprüft: bei der Anmeldung über Entra
// ist `user` ebenfalls gesetzt, und eine Prüfung auf `user` zuerst
// führte den Entra-Weg an app_upsert_user() vorbei — die Kennung wäre
// dann die `oid` statt app_users.id, und keine einzige Policy fände
// dazu eine Zeile.
if (!profile) {
if (user?.id) token.uid = user.id;
return token;
}
// `profile` liegt nur beim ersten Durchlauf nach der Rückkehr von Entra
// vor. Danach wird das Token nur noch weitergereicht — die Datenbank
// wird also einmal pro Anmeldung befragt, nicht einmal pro Aufruf.
const externalId = typeof profile.oid === "string" ? profile.oid : null;
const email = [profile.email, profile.preferred_username, profile.upn].find(
(v): v is string => typeof v === "string" && v.length > 0
);
// Lieber abbrechen als eine Sitzung ohne Kennung ausstellen: die käme
// als `null` bei withUser() an, und die Policies gäben dann konsequent
// nichts zurück — was sich als „die Anwendung ist leer" zeigt statt als
// Anmeldefehler.
if (!externalId || !email) throw new Error("Entra lieferte weder oid noch E-Mail-Adresse.");
token.uid = await upsertAppUser(externalId, email, typeof profile.name === "string" ? profile.name : null);
return token;
},
},
};
});

View File

@@ -0,0 +1,112 @@
"use client";
import Link from "next/link";
import { useState } from "react";
import { AenderungsTabelle } from "@/components/ui/AenderungsTabelle";
import { SlideOver } from "@/components/ui/SlideOver";
import { actionBadgeStyle } from "@/lib/colors";
import type { AuditChange } from "@/lib/types";
// Eine Protokollzeile zum Aufklappen.
//
// Die Liste zeigt, *dass* etwas geändert wurde; hier steht, *was*. Beides in
// der Tabelle unterzubringen ginge nicht — bei sieben geänderten Feldern
// wäre die Zeile höher als der Bildschirm.
export type AuditEintrag = {
id: string;
occurred_at: string;
actor_name: string;
action: string;
target_label: string;
target_employee_id: string | null;
details: string | null;
changes: AuditChange[] | null;
};
const zeitFormat = new Intl.DateTimeFormat("de-AT", {
day: "2-digit",
month: "2-digit",
year: "numeric",
hour: "2-digit",
minute: "2-digit",
second: "2-digit",
timeZone: "Europe/Vienna",
});
export function AuditDetail({ eintrag }: { eintrag: AuditEintrag }) {
const [offen, setOffen] = useState(false);
const anzahl = eintrag.changes?.length ?? 0;
return (
<>
<button
type="button"
onClick={() => setOffen(true)}
aria-haspopup="dialog"
className="w-full rounded px-2 py-1 text-left text-ink-muted hover:bg-brand-50 hover:text-ink
focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500"
>
<span>{eintrag.details ?? "–"}</span>
{anzahl > 0 && (
<span className="ml-2 whitespace-nowrap rounded-full bg-accent-100 px-2 py-0.5 text-[11px] font-semibold text-brand-700">
{anzahl} {anzahl === 1 ? "Feld" : "Felder"}
</span>
)}
</button>
<SlideOver
open={offen}
onClose={() => setOffen(false)}
title={eintrag.target_label}
subtitle={`${eintrag.action} · ${zeitFormat.format(new Date(eintrag.occurred_at))}`}
>
<dl className="grid grid-cols-[auto_1fr] gap-x-6 gap-y-2 text-sm">
<dt className="font-semibold text-ink-muted">Aktion</dt>
<dd>
<span className={`rounded-full px-2 py-0.5 text-[11px] font-semibold ${actionBadgeStyle(eintrag.action)}`}>
{eintrag.action}
</span>
</dd>
<dt className="font-semibold text-ink-muted">Benutzer:in</dt>
<dd className="text-ink">{eintrag.actor_name}</dd>
<dt className="font-semibold text-ink-muted">Zeitpunkt</dt>
<dd className="tabular-nums text-ink">{zeitFormat.format(new Date(eintrag.occurred_at))}</dd>
{eintrag.target_employee_id && (
<>
<dt className="font-semibold text-ink-muted">Objekt</dt>
<dd>
<Link
href={`/employees/${eintrag.target_employee_id}`}
className="rounded font-semibold text-brand-700 hover:underline
focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500"
>
{eintrag.target_label}
</Link>
</dd>
</>
)}
</dl>
{eintrag.details && (
<p className="mt-5 rounded-md bg-surface px-3 py-2 text-sm text-ink-body">{eintrag.details}</p>
)}
<h3 className="mt-6 text-sm font-bold text-ink">Geänderte Felder</h3>
{anzahl > 0 ? (
<div className="mt-2">
<AenderungsTabelle changes={eintrag.changes!} />
</div>
) : (
// Kein Aufzählungszeichen für „nichts da“: der Grund ist wichtig,
// damit niemand einen Fehler vermutet.
<p className="mt-2 max-w-prose text-sm text-ink-muted">
Für diesen Eintrag liegen keine Feldwerte vor. Vorgänge wie Eintritt, Austritt oder Import erfassen keine
Einzelfelder — und Einträge von vor der Erweiterung des Protokolls haben nur die Feldnamen behalten, nicht
die Werte. Nachliefern lässt sich das nicht.
</p>
)}
</SlideOver>
</>
);
}

View File

@@ -22,7 +22,11 @@ const ACTIONS: { value: string; label: string }[] = [
{ value: "Karenz", label: "Langzeitabwesenheit" },
{ value: "Vertragsänderung", label: "Vertragsänderung" },
{ value: "Stammdatenänderung", label: "Stammdatenänderung" },
{ value: "Gehaltsanpassung", label: "Gehaltsanpassung" },
// „Gehaltsanpassung" steht nicht mehr zur Auswahl: das Gehalt ist aus dem
// Funktionsumfang genommen (es wird in Loga geführt), keine Funktion
// schreibt diese Art mehr, und ein Filter, der immer leer ausgeht, sieht
// aus wie ein Fehler. Der Wert bleibt im Aufzählungstyp — alte Einträge
// aus der Zeit davor sollen lesbar bleiben.
];
export function AuditFilters() {

View File

@@ -0,0 +1,32 @@
"use client";
import { useFormStatus } from "react-dom";
// Eigene Schaltfläche statt der Button-Komponente: Microsoft gibt für „Sign in
// with Microsoft" Fläche, Schrift und Logo vor, und eine magentafarbene
// Variante wäre nicht nur regelwidrig, sondern auch irreführend — sie sähe aus
// wie eine Aktion *in* dieser Anwendung, während sie in Wirklichkeit auf eine
// fremde Anmeldeseite springt.
export function EntraSignInButton() {
const { pending } = useFormStatus();
return (
<button
type="submit"
disabled={pending}
aria-busy={pending || undefined}
className="inline-flex w-full items-center justify-center gap-3 rounded-md border border-[#8c8c8c] bg-white px-4 py-3
text-sm font-semibold text-[#5e5e5e] transition-colors hover:bg-[#f3f3f3]
focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500
disabled:cursor-not-allowed disabled:opacity-60"
>
<svg viewBox="0 0 21 21" className="h-[18px] w-[18px] shrink-0" aria-hidden="true">
<rect x="1" y="1" width="9" height="9" fill="#f25022" />
<rect x="11" y="1" width="9" height="9" fill="#7fba00" />
<rect x="1" y="11" width="9" height="9" fill="#00a4ef" />
<rect x="11" y="11" width="9" height="9" fill="#ffb900" />
</svg>
{pending ? "Weiterleitung zu Microsoft…" : "Mit Firmenkonto anmelden"}
</button>
);
}

View File

@@ -0,0 +1,105 @@
"use client";
import Link from "next/link";
import { useActionState, useState } from "react";
import { passwortAendern, type WechselZustand } from "@/actions/passwort";
import { Button } from "@/components/ui/Button";
import { CONTROL_CLASS, Field } from "@/components/ui/Field";
import { PASSWORT_REGELN, passwortBeanstandung } from "@/lib/passwort";
// Das eigene Passwort wechseln.
//
// Die Regeln stehen schon beim Tippen da, statt erst nach dem Absenden — beim
// erzwungenen Wechsel ist das der erste Bildschirm, den jemand in dieser
// Anwendung sieht, und dreimal abgewiesen zu werden ist ein schlechter Anfang.
// Abgewiesen oder angenommen wird trotzdem in der Datenbank; hier steht nur
// eine Vorabanzeige (lib/passwort.ts).
const START: WechselZustand = { fehler: null };
export function PasswortAendernFormular({ erzwungen }: { erzwungen: boolean }) {
const [zustand, aktion, laeuft] = useActionState(passwortAendern, START);
const [neues, setNeues] = useState("");
const [wiederholung, setWiederholung] = useState("");
// Erst beanstanden, wenn etwas dasteht: ein leeres Feld ist noch kein Fehler.
const beanstandung = neues ? passwortBeanstandung(neues) : null;
const passtNichtZusammen = wiederholung.length > 0 && neues !== wiederholung;
return (
<form action={aktion} className="flex flex-col gap-4">
{zustand.fehler && (
<p role="alert" className="rounded-md border border-danger-text/20 bg-danger-bg px-3 py-2 text-sm text-danger-text">
{zustand.fehler}
</p>
)}
<Field label="Bisheriges Passwort">
{(p) => (
<input {...p} name="altes_passwort" type="password" required autoComplete="current-password" className={CONTROL_CLASS} />
)}
</Field>
<Field
label="Neues Passwort"
error={beanstandung}
hint={`Erforderlich: ${PASSWORT_REGELN.join(", ")}.`}
>
{(p) => (
<input
{...p}
name="neues_passwort"
type="password"
required
autoComplete="new-password"
value={neues}
onChange={(e) => setNeues(e.target.value)}
className={CONTROL_CLASS}
/>
)}
</Field>
<Field label="Neues Passwort wiederholen" error={passtNichtZusammen ? "Die beiden Eingaben stimmen nicht überein." : null}>
{(p) => (
<input
{...p}
name="wiederholung"
type="password"
required
autoComplete="new-password"
value={wiederholung}
onChange={(e) => setWiederholung(e.target.value)}
className={CONTROL_CLASS}
/>
)}
</Field>
{/* Gesperrt, solange die Vorabanzeige etwas zu beanstanden hat. Das ist
Bequemlichkeit, keine Absicherung — wer die Schaltfläche freischaltet,
landet in app_passwort_regeln() und wird dort abgewiesen. */}
<Button
type="submit"
fullWidth
disabled={Boolean(beanstandung) || passtNichtZusammen}
pending={laeuft}
pendingLabel="Wird gespeichert…"
>
Passwort ändern
</Button>
{/* `Link` und nicht `<a>`: ein gewöhnlicher Verweis auf eine Seite dieser
Anwendung lädt das Dokument neu und damit das ganze Bündel — der Weg
zurück fühlte sich an wie ein Neustart. eslint-config-next weist das
ab, und zu Recht. */}
{!erzwungen && (
<Link
href="/"
className="rounded text-center text-xs text-ink-muted underline underline-offset-2 hover:no-underline
focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500"
>
Zurück zur Anwendung
</Link>
)}
</form>
);
}

View File

@@ -0,0 +1,54 @@
"use client";
import { useActionState } from "react";
import { anmeldenMitPasswort, type AnmeldeZustand } from "@/actions/auth";
import { Button } from "@/components/ui/Button";
import { CONTROL_CLASS, Field } from "@/components/ui/Field";
// Anmeldung mit Passwort — der zweite Weg neben dem Firmenkonto, auf Zeit
// (siehe actions/auth.ts).
//
// Die Meldung kommt aus der Server Action und ist für jeden Fehlschlag
// dieselbe. Kein `autoFocus`: die Seite bietet zwei Wege an, und der obere ist
// der gemeinte — den Cursor unten hineinzusetzen kehrte das um.
const START: AnmeldeZustand = { fehler: null };
export function PasswortFormular() {
const [zustand, aktion, laeuft] = useActionState(anmeldenMitPasswort, START);
return (
<form action={aktion} className="flex flex-col gap-3">
{zustand.fehler && (
<p role="alert" className="rounded-md border border-danger-text/20 bg-danger-bg px-3 py-2 text-sm text-danger-text">
{zustand.fehler}
</p>
)}
<Field label="E-Mail-Adresse">
{(p) => (
<input
{...p}
name="email"
type="email"
required
// `username`, nicht `email`: nur so bietet der Passwortspeicher des
// Browsers das Paar aus Adresse und Passwort gemeinsam an.
autoComplete="username"
className={CONTROL_CLASS}
/>
)}
</Field>
<Field label="Passwort">
{(p) => (
<input {...p} name="passwort" type="password" required autoComplete="current-password" className={CONTROL_CLASS} />
)}
</Field>
<Button type="submit" fullWidth pending={laeuft} pendingLabel="Anmelden…">
Anmelden
</Button>
</form>
);
}

94
components/brand/Logo.tsx Normal file
View File

@@ -0,0 +1,94 @@
// Das Manner-Logo und die Wortmarke der Anwendung — an einer Stelle, weil
// Kopfleiste und Anmeldeseite dasselbe zeigen sollen.
//
// ═══ Welches Logo ═══
//
// Verwendet wird das **Markenlogo** (CD §4.1): der Schriftzug allein, ohne
// den Stephansdom-Medaillon. Das Unternehmenslogo (§3.1) waere nach §3.2 das
// formal richtige, wo „Josef Manner & Comp. AG" als Absender auftritt — es
// steht hier aber nicht zur Verfuegung.
//
// ═══ Eine Datei, zwei Faelle ═══
//
// Die Vorlage ist ein PNG mit durchsichtigem Grund: nur der Schriftzug, blau
// (#164194, der Wert aus §1.1) mit weisser Kontur, kein Feld darunter.
//
// §1.2 laesst den Schriftzug ausschliesslich zur Gaenze auf Rosa zu, und das
// Manual kennt dafuer zwei Lagen:
//
// • **In einem grossflaechigen rosa Umfeld** (§3.1) wird er „mit genuegend
// Freiraum rundum integriert" — die Flaeche ist schon da. Das ist
// `aufRosa`: nur Freiraum, kein eigener Grund.
//
// • **Auf Weiss** (§4.1) gehoert er „in ein rechteckiges rosa Feld, das den
// Regeln des Freiraums folgt". Dieses Feld zeichnet das Bauteil selbst,
// aus derselben Polsterung.
//
// Vorher lagen dafuer zwei SVG nebeneinander, eines mit eingebackenem Feld
// und eines ohne. Das war eine Datei zu viel — und die Fassung mit Feld liess
// sich auf einer rosa Flaeche nicht sauber unterbringen, weil ihr Rechteck
// sichtbar blieb, sobald ueber der Flaeche noch irgendetwas lag.
//
// Als <img> und nicht inline: der Browser holt die Datei einmal und nimmt sie
// danach aus dem Zwischenspeicher, statt sie in jeder Seitenauslieferung
// mitzuschleppen.
/** Seitenverhaeltnis der Vorlage: 1203 x 484 Pixel. */
const VERHAELTNIS = 1203 / 484;
export function MannerLogo({
hoehe = 28,
aufRosa = false,
className = "",
}: {
hoehe?: number;
/** Fuer rosa Untergruende: ohne eigenes Feld, nur mit Freiraum. */
aufRosa?: boolean;
className?: string;
}) {
const breite = Math.round(hoehe * VERHAELTNIS);
// Der Freiraum nach §4.1: X/3, wobei X als Hoehe des Schriftzugs gelesen
// ist. Er steckt hier und nicht in den Aufrufstellen — sonst haengt seine
// Einhaltung daran, dass jede einzelne daran denkt.
const freiraum = Math.round(hoehe / 3);
return (
<span
style={{ padding: freiraum }}
// Ohne Eckenrundung: §4.1 spricht von einem rechteckigen Feld.
className={`inline-flex shrink-0 items-center ${aufRosa ? "" : "bg-accent-500"} ${className}`}
>
{/* next/image bringt Groessenvarianten und Ladelogik fuer Fotos mit; fuer
eine Bildmarke fester Groesse ist beides Ballast. */}
{/* eslint-disable-next-line @next/next/no-img-element */}
<img src="/brand/manner-logo.png" alt="Manner" width={breite} height={hoehe} style={{ width: breite, height: hoehe }} />
</span>
);
}
/**
* Logo plus Produktname.
*
* Die beiden gehoeren zusammen und meinen Verschiedenes: das Logo sagt, wem
* das System gehoert, der Name sagt, was es ist.
*/
export function AppWortmarke({
hoehe = 26,
aufRosa = false,
textKlasse = "text-ink",
className = "",
}: {
hoehe?: number;
aufRosa?: boolean;
textKlasse?: string;
className?: string;
}) {
return (
// Nur ein schmaler Abstand: den Hauptteil der Trennung leistet der
// Freiraum des Logos, der ohnehin frei bleiben muss.
<span className={`flex items-center gap-2 ${className}`}>
<MannerLogo hoehe={hoehe} aufRosa={aufRosa} />
<span className={`text-base font-extrabold tracking-tight ${textKlasse}`}>Alpenwerk HR</span>
</span>
);
}

View File

@@ -0,0 +1,70 @@
"use client";
import { usePathname, useRouter, useSearchParams } from "next/navigation";
import { SegmentedControl } from "@/components/ui/SegmentedControl";
import { ANSTEHEND_STYLES } from "@/lib/colors";
import {
ANSTEHEND_ARTEN,
STANDARD_ZEITRAUM,
ZEITRAEUME,
type AnstehendArt,
type Zeitraum,
} from "@/lib/dashboard-filter";
// Die Auswahl wandert in die Adresse; die Seite baut sich damit neu. Das ist
// hier nötig und nicht bloss ordentlich: ein längerer Zeitraum bringt Zeilen
// ins Spiel, die vorher gar nicht geladen waren.
//
// router.replace statt push, damit der Zurück-Knopf nicht durch jede einzelne
// Filterstellung zurückläuft, und ohne Sprung nach oben — die Karte steht in
// der unteren Hälfte, und dorthin sieht gerade, wer hier klickt.
export function AnstehendFilter({ zeitraum, arten }: { zeitraum: Zeitraum; arten: AnstehendArt[] }) {
const router = useRouter();
const pathname = usePathname();
const searchParams = useSearchParams();
function setzen(key: string, wert: string | null) {
const params = new URLSearchParams(searchParams.toString());
if (wert) params.set(key, wert);
else params.delete(key);
const query = params.toString();
router.replace(query ? `${pathname}?${query}` : pathname, { scroll: false });
}
function artUmschalten(art: AnstehendArt) {
const alle = ANSTEHEND_ARTEN.map((a) => a.value);
const naechste = arten.includes(art) ? arten.filter((a) => a !== art) : [...arten, art];
// Nichts ausgewählt heisst wieder alles: eine leere Karte ist keine
// Antwort, und der Weg dorthin wäre ein Klick zu weit.
setzen("arten", naechste.length === 0 || naechste.length === alle.length ? null : naechste.join(","));
}
return (
<div className="mb-2 flex flex-wrap items-center gap-2">
<SegmentedControl<string>
value={String(zeitraum)}
onChange={(v) => setzen("tage", v === String(STANDARD_ZEITRAUM) ? null : v)}
options={ZEITRAEUME.map((t) => ({ value: String(t), label: `${t} Tage` }))}
/>
<div className="flex flex-wrap items-center gap-1.5">
{ANSTEHEND_ARTEN.map((a) => {
const aktiv = arten.includes(a.value);
return (
<button
key={a.value}
type="button"
onClick={() => artUmschalten(a.value)}
aria-pressed={aktiv}
className={`rounded-full px-2 py-0.5 text-xs font-semibold focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500 ${
aktiv ? ANSTEHEND_STYLES[a.value] : "bg-surface text-ink-muted hover:text-ink"
}`}
>
{a.label}
</button>
);
})}
</div>
</div>
);
}

View File

@@ -0,0 +1,148 @@
"use client";
import Link from "next/link";
import { useState } from "react";
import { fmtDate } from "@/lib/format";
export const KIND_LABEL = {
hire: "Eintritt",
exit: "Austritt",
return: "Rückkehr aus Abwesenheit",
note: "Wiedervorlage",
} as const;
export type AnstehendEintrag = {
id: string;
/** Ziel des Klicks — bei einer Wiedervorlage die Akte, nicht die Notiz. */
employeeId: string;
label: string;
/** Zweite Zeile: bei einer Wiedervorlage der Notiztext statt der Art. */
hinweis?: string;
date: string;
kind: keyof typeof KIND_LABEL;
};
/** Wie viele Zeilen die Karte zeigt, bevor aufgeklappt wird. */
export const VORSCHAU = 8;
/**
* Die Karte bleibt eine Übersicht — acht Zeilen, und darunter steht, wie
* viele es insgesamt sind. Neu ist, dass diese Zeile ein Knopf ist: wer alle
* sehen will, klappt sie auf, statt den Zeitraum enger zu stellen und die
* Antwort damit zu verändern.
*
* Das geschieht im Browser und nicht über die Adresse, anders als bei
* Zeitraum und Art: die Einträge sind bereits alle geladen, es gibt nichts
* nachzuholen. Ein Umweg über den Server brächte eine Wartezeit für Daten,
* die schon da sind — und einen Eintrag im Verlauf für etwas, das niemand
* zurückgehen will.
*/
export function AnstehendListe({
eintraege,
today,
leerText,
}: {
eintraege: AnstehendEintrag[];
today: string;
leerText: string;
}) {
const [alle, setAlle] = useState(false);
// Namensfilter aus dem Workshop (Anforderung 2). Im Browser und nicht über
// die Adresse, aus demselben Grund wie das Aufklappen: die Einträge sind
// vollständig geladen, es gibt nichts nachzuholen.
const [suche, setSuche] = useState("");
const begriff = suche.trim().toLowerCase();
// Wortweise und am Wortanfang — dieselbe Regel wie in der Mitarbeiterliste,
// damit „gru" Gruber findet und nicht auch jede Notiz mit „Arbeitsgruppe".
// Der Hinweis wird bewusst nicht durchsucht: gesucht wird nach Personen.
const gefiltert = begriff
? eintraege.filter((e) =>
e.label
.toLowerCase()
.split(/[\s,;/-]+/)
.some((wort) => wort.startsWith(begriff))
)
: eintraege;
const sichtbar = alle ? gefiltert : gefiltert.slice(0, VORSCHAU);
const weitere = gefiltert.length - sichtbar.length;
return (
<>
{/* Immer da, sobald überhaupt etwas ansteht.
*
Zuerst stand hier eine Schwelle — erst ab neun Einträgen, weil man
darunter die ganze Liste ohnehin sieht. In der Bedienung war das
falsch: das Feld erschien bei 180 Tagen und verschwand bei 30, und
ein Bedienelement, das je nach Zeitraum da ist oder nicht, wirkt wie
ein Fehler. Wer sucht, sucht auch in sieben Zeilen. */}
{eintraege.length > 0 && (
<input
type="search"
value={suche}
onChange={(e) => setSuche(e.target.value)}
placeholder="Name filtern…"
aria-label="Anstehende Ereignisse nach Name filtern"
className="mb-2 w-full rounded border border-border-strong bg-white px-2.5 py-1.5 text-sm text-ink
placeholder:text-ink-muted focus-visible:outline-2 focus-visible:outline-offset-1 focus-visible:outline-brand-500"
/>
)}
<ul className="flex flex-col divide-y divide-border-subtle">
{sichtbar.map((item) => {
// Überfällig gibt es nur bei Wiedervorlagen: die anderen Arten
// haben eine untere Grenze, eine offene Aufgabe nicht.
const ueberfaellig = item.date < today;
return (
<li key={`${item.kind}-${item.id}`}>
<Link
href={`/employees/${item.employeeId}`}
className="-mx-2 flex items-center justify-between gap-2 rounded px-2 py-2.5 text-sm hover:bg-surface"
>
<span className="min-w-0">
<span className="block truncate font-semibold text-ink">{item.label}</span>
<span className="block truncate text-xs text-ink-muted">
{KIND_LABEL[item.kind]}
{item.hinweis ? ` — ${item.hinweis}` : ""}
</span>
</span>
<span
className={`shrink-0 text-xs font-semibold tabular-nums ${
ueberfaellig ? "text-danger-text" : "text-ink-muted"
}`}
>
{ueberfaellig ? "überfällig " : ""}
{fmtDate(item.date)}
</span>
</Link>
</li>
);
})}
{eintraege.length === 0 && <p className="py-2 text-sm text-ink-muted">{leerText}</p>}
{/* Ein leeres Ergebnis mit Suchbegriff ist etwas anderes als eine
leere Karte: der Zeitraum stimmt, nur der Name passt nicht. */}
{eintraege.length > 0 && gefiltert.length === 0 && (
<p className="py-2 text-sm text-ink-muted">
Kein Name passt zu „{suche.trim()}&ldquo;. {eintraege.length}{" "}
{eintraege.length === 1 ? "Ereignis steht" : "Ereignisse stehen"} an.
</p>
)}
</ul>
{/* Der Knopf steht nur da, wenn es etwas zu holen gibt. Ist die Liste
aufgeklappt, führt er wieder zurück — sonst bliebe die Karte für den
Rest der Sitzung lang, auch wenn jemand nur einmal nachsehen
wollte. */}
{(weitere > 0 || alle) && (
<button
type="button"
onClick={() => setAlle((v) => !v)}
aria-expanded={alle}
className="mt-2 rounded text-xs font-semibold text-brand-700 hover:underline focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500"
>
{alle
? "Weniger anzeigen"
: `… und ${weitere} ${weitere === 1 ? "weiteres Ereignis" : "weitere Ereignisse"} anzeigen`}
</button>
)}
</>
);
}

View File

@@ -1,16 +1,30 @@
"use client";
import { Trash2 } from "lucide-react";
import { Lock, Trash2 } from "lucide-react";
import { useRouter } from "next/navigation";
import { useTransition } from "react";
import { deleteHireDraft } from "@/actions/hireDrafts";
import { useHireWizard } from "@/components/hire/HireWizardContext";
import { useToast } from "@/components/ui/Toast";
import type { Entwurf } from "@/lib/entwuerfe";
import { fmtDate } from "@/lib/format";
type Draft = { id: string; step: number; payload: Record<string, unknown>; updated_at: string };
// Angefangene Neueinstellungen — die eigenen und, wer in der Glocke
// hinzugewählt ist, auch dessen.
//
// Fortsetzen geht bei beiden: wer vertreten wird, soll die angefangene
// Einstellung zu Ende bringen können. Aber immer nur eine Person zugleich —
// der Entwurf ist ein einziges JSONB-Feld, zwei gleichzeitig Schreibende
// überschrieben einander vollständig, und die Zweite merkte nichts davon.
// Die Sperre dazu steht in der Datenbank (20260910160000); hier steht nur,
// was sie für die Zeile bedeutet.
//
// Löschen bleibt beim Eigentümer. Die Regel liesse mehr zu — sie muss, weil
// der Assistent den Entwurf nach dem Anlegen selbst wegräumt —, aber eine
// Schaltfläche, die fremde halbfertige Arbeit wegwirft, gehört nicht neben
// eine, die sie fortsetzt.
export function DraftsCard({ drafts }: { drafts: Draft[] }) {
export function DraftsCard({ drafts }: { drafts: Entwurf[] }) {
const { openWizard } = useHireWizard();
const { showToast } = useToast();
const router = useRouter();
@@ -39,24 +53,46 @@ export function DraftsCard({ drafts }: { drafts: Draft[] }) {
const lastName = typeof d.payload.lastName === "string" ? d.payload.lastName : "";
const name = [firstName, lastName].filter(Boolean).join(" ") || "Ohne Namen";
return (
<li key={d.id} className="flex items-center justify-between py-2 text-sm">
<li key={d.id} className="flex items-center justify-between gap-3 py-2 text-sm">
<div>
<span className="font-semibold text-ink">{name}</span>
<span className="ml-2 text-xs text-ink-muted">Gespeichert am {fmtDate(d.updated_at)}</span>
{/* An jeder Zeile, wie an den Notizen in der Glocke: seit
fremde Entwürfe dazwischenstehen, ist ohne die Angabe nicht
zu sehen, welcher wessen ist. „von mir" statt des eigenen
Namens — den kennt man. */}
<span className="ml-2 text-xs text-ink-muted">{d.vonMir ? "von mir" : `von ${d.autor}`}</span>
</div>
<div className="flex items-center gap-3">
<button type="button" onClick={() => openWizard({ draftId: d.id })} className="text-xs font-semibold text-brand-700 hover:underline">
Fortsetzen
</button>
<button
type="button"
onClick={() => handleDelete(d.id)}
disabled={pending}
aria-label="Entwurf löschen"
className="text-ink-muted hover:text-danger-solid"
>
<Trash2 className="h-4 w-4" />
</button>
{d.gesperrtVon ? (
// Mit dem Grund daneben, nicht bloss abgeschaltet: eine
// graue Schaltfläche ohne Erklärung liest sich wie ein
// Fehler, und die nächste Handlung wäre, es gleich noch
// einmal zu versuchen.
<span className="flex shrink-0 items-center gap-1 text-xs text-ink-muted">
<Lock className="h-3.5 w-3.5" />
{d.gesperrtVon} bearbeitet gerade
</span>
) : (
<button
type="button"
onClick={() => openWizard({ draftId: d.id })}
className="text-xs font-semibold text-brand-700 hover:underline"
>
Fortsetzen
</button>
)}
{d.vonMir && (
<button
type="button"
onClick={() => handleDelete(d.id)}
disabled={pending || Boolean(d.gesperrtVon)}
aria-label="Entwurf löschen"
className="text-ink-muted hover:text-danger-solid disabled:opacity-40"
>
<Trash2 className="h-4 w-4" />
</button>
)}
</div>
</li>
);

View File

@@ -2,34 +2,48 @@
import { useRouter } from "next/navigation";
import { useState } from "react";
import { addEmployeeDependent } from "@/actions/employees";
import { addEmployeeDependent, updateEmployeeDependent } from "@/actions/employees";
import { Button } from "@/components/ui/Button";
import { SelectField, TextField } from "@/components/ui/Field";
import { Modal } from "@/components/ui/Modal";
import { useToast } from "@/components/ui/Toast";
import { todayIso } from "@/lib/format";
import type { RelationshipType } from "@/lib/supabase/types";
import type { Database, RelationshipType } from "@/lib/types";
const RELATIONSHIPS: RelationshipType[] = ["Ehepartner:in", "Lebenspartner:in", "Kind", "Sonstige"];
type Dependent = Database["public"]["Tables"]["employee_dependents"]["Row"];
// Dasselbe Fenster für Anlegen und Berichtigen.
//
// Der Unterschied ist nicht die Maske, sondern der Stichtag: beim Anlegen
// passiert etwas zu einem Zeitpunkt, beim Berichtigen war die Angabe schon
// vorher falsch. Deshalb steht „Wirksam ab" nur im ersten Fall — ein Datum
// bei einer Korrektur hiesse, die Person habe bis dahin anders geheissen.
export function AddDependentModal({
open,
onClose,
employeeId,
defaultEffectiveDate,
dependent,
}: {
open: boolean;
onClose: () => void;
employeeId: string;
defaultEffectiveDate?: string;
/** Gesetzt: berichtigen statt anlegen. */
dependent?: Dependent;
}) {
const { showToast } = useToast();
const router = useRouter();
const [firstName, setFirstName] = useState("");
const [lastName, setLastName] = useState("");
const [svNummer, setSvNummer] = useState("");
const [birthDate, setBirthDate] = useState("");
const [relationship, setRelationship] = useState<RelationshipType>("Kind");
const bearbeiten = Boolean(dependent);
const [firstName, setFirstName] = useState(dependent?.first_name ?? "");
const [lastName, setLastName] = useState(dependent?.last_name ?? "");
const [svNummer, setSvNummer] = useState(dependent?.sv_nummer ?? "");
const [birthDate, setBirthDate] = useState(dependent?.birth_date ?? "");
const [relationship, setRelationship] = useState<RelationshipType>(
(dependent?.relationship as RelationshipType) ?? "Kind"
);
const [effectiveDate, setEffectiveDate] = useState(defaultEffectiveDate ?? todayIso());
const [prevDefaultEffectiveDate, setPrevDefaultEffectiveDate] = useState(defaultEffectiveDate);
const [pending, setPending] = useState(false);
@@ -53,26 +67,36 @@ export function AddDependentModal({
}
async function handleSubmit() {
if (!firstName || !lastName || !birthDate || !effectiveDate) {
if (!firstName || !lastName || !birthDate || (!bearbeiten && !effectiveDate)) {
showToast("Bitte alle Pflichtfelder ausfüllen.", "error");
return;
}
setPending(true);
const result = await addEmployeeDependent({
employee_id: employeeId,
first_name: firstName,
last_name: lastName,
relationship,
sv_nummer: svNummer || undefined,
birth_date: birthDate,
effective_date: effectiveDate,
});
const result = bearbeiten
? await updateEmployeeDependent({
dependent_id: dependent!.id,
employee_id: employeeId,
first_name: firstName,
last_name: lastName,
relationship,
sv_nummer: svNummer,
birth_date: birthDate,
})
: await addEmployeeDependent({
employee_id: employeeId,
first_name: firstName,
last_name: lastName,
relationship,
sv_nummer: svNummer || undefined,
birth_date: birthDate,
effective_date: effectiveDate,
});
setPending(false);
if (result.success) {
showToast("Angehörige:r hinzugefügt.");
showToast(bearbeiten ? "Angaben berichtigt." : "Angehörige:r hinzugefügt.");
router.refresh();
onClose();
reset();
if (!bearbeiten) reset();
} else {
showToast(result.error ?? "Fehler beim Speichern.", "error");
}
@@ -82,20 +106,22 @@ export function AddDependentModal({
<Modal
open={open}
onClose={onClose}
title="Angehörige:n hinzufügen"
title={bearbeiten ? "Angehörige:n berichtigen" : "Angehörige:n hinzufügen"}
footer={
<>
<Button variant="ghost" onClick={onClose}>
Abbrechen
</Button>
<Button onClick={handleSubmit} pending={pending}>
Hinzufügen
{bearbeiten ? "Speichern" : "Hinzufügen"}
</Button>
</>
}
>
<div className="flex flex-col gap-4">
<TextField label="Wirksam ab" required type="date" value={effectiveDate} onChange={setEffectiveDate} />
{!bearbeiten && (
<TextField label="Wirksam ab" required type="date" value={effectiveDate} onChange={setEffectiveDate} />
)}
<div className="grid grid-cols-1 gap-3 sm:grid-cols-2">
<TextField label="Vorname" required value={firstName} onChange={setFirstName} />
<TextField label="Nachname" required value={lastName} onChange={setLastName} />

View File

@@ -1,13 +1,13 @@
"use client";
import { Plus, Trash2 } from "lucide-react";
import { Pencil, Plus, Trash2 } from "lucide-react";
import { useRouter } from "next/navigation";
import { useState } from "react";
import { deleteEmployeeDependent } from "@/actions/employees";
import { Button } from "@/components/ui/Button";
import { useToast } from "@/components/ui/Toast";
import { fmtDate, todayIso } from "@/lib/format";
import type { Database } from "@/lib/supabase/types";
import type { Database } from "@/lib/types";
import { AddDependentModal } from "./AddDependentModal";
type Dependent = Database["public"]["Tables"]["employee_dependents"]["Row"];
@@ -19,6 +19,7 @@ export function AngehoerigeSection({ employeeId, dependents, effectiveDate }: {
const { showToast } = useToast();
const router = useRouter();
const [modalOpen, setModalOpen] = useState(false);
const [bearbeitet, setBearbeitet] = useState<Dependent | null>(null);
const [deletingId, setDeletingId] = useState<string | null>(null);
const resolvedEffectiveDate = effectiveDate || todayIso();
@@ -52,7 +53,7 @@ export function AngehoerigeSection({ employeeId, dependents, effectiveDate }: {
<div className="overflow-x-auto rounded border border-border">
<table className="w-full min-w-[600px] text-sm">
<thead>
<tr className="border-b border-border bg-brand-50 text-left text-xs font-semibold uppercase tracking-wide text-ink-muted">
<tr className="border-b border-border bg-accent-50 text-left text-xs font-semibold uppercase tracking-wide text-ink-muted">
<th className="px-4 py-2.5">Name</th>
<th className="px-4 py-2.5">Verhältnis</th>
<th className="px-4 py-2.5">SVNR</th>
@@ -70,6 +71,18 @@ export function AngehoerigeSection({ employeeId, dependents, effectiveDate }: {
<td className="px-4 py-2.5 text-ink-body">{d.sv_nummer ?? "–"}</td>
<td className="px-4 py-2.5 text-ink-body">{fmtDate(d.birth_date)}</td>
<td className="px-4 py-2.5 text-right">
{/* Berichtigen statt löschen-und-neu-anlegen: ein
Tippfehler hinterliess sonst zwei Einträge in der
Akte, und der erste sagte „entfernt", was nicht
stimmte. */}
<Button
variant="icon"
onClick={() => setBearbeitet(d)}
aria-label={`${d.first_name} ${d.last_name} berichtigen`}
className="hover:!text-brand-700"
>
<Pencil className="h-3.5 w-3.5" />
</Button>
<Button
variant="icon"
onClick={() => handleDelete(d.id)}
@@ -88,6 +101,19 @@ export function AngehoerigeSection({ employeeId, dependents, effectiveDate }: {
)}
<AddDependentModal open={modalOpen} onClose={() => setModalOpen(false)} employeeId={employeeId} defaultEffectiveDate={resolvedEffectiveDate} />
{/* Eigene Einbindung mit `key`: das Fenster bleibt sonst montiert und
zeigte beim zweiten Öffnen die Felder der zuvor bearbeiteten
Person. */}
{bearbeitet && (
<AddDependentModal
key={bearbeitet.id}
open
onClose={() => setBearbeitet(null)}
employeeId={employeeId}
dependent={bearbeitet}
/>
)}
</div>
);
}

View File

@@ -6,61 +6,86 @@ import { useState } from "react";
import { Avatar } from "@/components/ui/Avatar";
import { Button } from "@/components/ui/Button";
import { StatusChip } from "@/components/ui/StatusChip";
import type { AufgabenStand } from "@/lib/checklist";
import { fmtFullName, tenure } from "@/lib/format";
import type { Database } from "@/lib/supabase/types";
import { fortschritt as fortschrittOffboarding, gehoertOffboarding } from "@/lib/offboarding";
import { fortschritt as fortschrittOnboarding } from "@/lib/onboarding";
import type { OpenPositionResolved } from "@/lib/positions";
import { deriveStatusAsOf } from "@/lib/reports";
import type { Database } from "@/lib/types";
import { DatenAendernPanel } from "./panels/DatenAendernPanel";
import { KarenzPanel } from "./panels/KarenzPanel";
import { PromotePanel } from "./panels/PromotePanel";
import { RehirePanel } from "./panels/RehirePanel";
import { RehireWizard } from "../hire/RehireWizard";
import { TerminatePanel } from "./panels/TerminatePanel";
import { TransferPanel } from "./panels/TransferPanel";
import { HistorieTab } from "./tabs/HistorieTab";
import { NotizenTab } from "./tabs/NotizenTab";
import { OffboardingTab } from "./tabs/OffboardingTab";
import { OnboardingTab } from "./tabs/OnboardingTab";
import { OrganisationTab } from "./tabs/OrganisationTab";
import { StammdatenTab } from "./tabs/StammdatenTab";
import { VertragTab } from "./tabs/VertragTab";
type EmployeeRow = Database["public"]["Tables"]["employees"]["Row"];
type Division = Database["public"]["Tables"]["divisions"]["Row"];
type Department = Database["public"]["Tables"]["departments"]["Row"];
type Team = Database["public"]["Tables"]["teams"]["Row"];
type Location = Database["public"]["Tables"]["locations"]["Row"];
type HistoryRow = Database["public"]["Tables"]["employee_history"]["Row"];
type Dependent = Database["public"]["Tables"]["employee_dependents"]["Row"];
type NoteRow = Database["public"]["Tables"]["employee_notes"]["Row"];
type MiniEmployee = { id: string; first_name: string; last_name: string; job_title: string; status?: string };
type OpenPosition = { id: string; position_number: string; title: string; team_id: string; is_lead: boolean };
/** Die Planstelle, die die Person heute innehat. */
type PlacementInfo = { positionNumber: string; jobTitle: string; isChief: boolean; current: boolean };
type EmployeeDetailProps = {
employee: EmployeeRow;
placement: PlacementInfo | null;
breadcrumb: string;
/** Die Kostenstelle der laufenden Planstellenbesetzung. */
kostenstelle: { code: string; name: string } | null;
/** Der Stand der Onboarding-Checkliste; leer heisst: es gibt keine. */
onboarding: AufgabenStand[];
/** Der Stand der Offboarding-Checkliste; leer heisst: es gibt keine. */
offboarding: AufgabenStand[];
manager: MiniEmployee | null;
/** Nur gesetzt, wenn die zuständige Leitung abwesend ist und vertreten wird. */
formalManager: MiniEmployee | null;
directReports: MiniEmployee[];
history: HistoryRow[];
dependents: Dependent[];
notes: NoteRow[];
divisions: Division[];
departments: Department[];
teams: Team[];
locations: Location[];
openPositions: OpenPosition[];
openPositions: OpenPositionResolved[];
/** Der Tag, zu dem die Akte gelesen wurde — derselbe wie in loadEmployeeDetail. */
today: string;
};
type PanelType = "transfer" | "promote" | "karenz" | "daten" | "terminate" | "rehire" | null;
const TABS = ["Stammdaten", "Vertrag", "Organisation", "Historie", "HR-Notizen"] as const;
const ALLE_TABS = ["Stammdaten", "Vertrag", "Organisation", "Onboarding", "Offboarding", "Historie", "HR-Notizen"] as const;
type Tab = (typeof ALLE_TABS)[number];
export function EmployeeDetail(props: EmployeeDetailProps) {
const { employee, manager, directReports, history, dependents, notes, divisions, departments, teams, locations } = props;
const [tab, setTab] = useState<(typeof TABS)[number]>("Stammdaten");
const { employee, placement, breadcrumb, kostenstelle, onboarding, offboarding, manager, formalManager, directReports, history, dependents, notes, locations, openPositions, today } = props;
const [tab, setTab] = useState<Tab>("Stammdaten");
const [panel, setPanel] = useState<PanelType>(null);
const division = divisions.find((d) => d.id === employee.division_id);
const team = employee.team_id ? teams.find((t) => t.id === employee.team_id) : undefined;
const department = team ? departments.find((d) => d.id === team.department_id) : undefined;
const breadcrumb = [division?.name, department?.name, team?.name].filter(Boolean).join(" › ") || "–";
const location = locations.find((l) => l.id === employee.location_id);
// Am Reiter steht, was noch aussteht — sonst müsste man hineinsehen, um zu
// erfahren, dass nichts zu tun ist.
const offeneOnboarding = onboarding.length > 0 ? fortschrittOnboarding(onboarding).gesamt - fortschrittOnboarding(onboarding).erledigt : 0;
const offeneOffboarding = offboarding.length > 0 ? fortschrittOffboarding(offboarding).gesamt - fortschrittOffboarding(offboarding).erledigt : 0;
const isActive = employee.status === "Aktiv" || employee.status === "Karenz";
const canEditData = employee.status !== "Ausgetreten";
const zeigtOffboarding = gehoertOffboarding(employee);
const tabs = ALLE_TABS.filter((t) => t !== "Offboarding" || zeigtOffboarding);
// Abgeleitet, nicht aus `employee.status` gelesen. Die Spalte hängt nach,
// wenn ein Austritt mit einem damals künftigen Datum erfasst wurde — es gibt
// keinen Lauf, der sie später nachzieht (Migration 20260814100000). Hier
// entschied sie nicht nur über eine Beschriftung, sondern über die Knöpfe:
// an einer Person, die seit zwei Wochen ausgetreten ist, stand „Austritt"
// weiter zur Verfügung, und „Daten ändern" ebenfalls.
const status = deriveStatusAsOf(employee, today);
const isActive = status === "Aktiv" || status === "Karenz";
const canEditData = status !== "Ausgetreten";
return (
<div className="flex flex-col gap-6">
@@ -77,13 +102,22 @@ export function EmployeeDetail(props: EmployeeDetailProps) {
<h2 className="text-xl font-extrabold text-ink">
{fmtFullName(employee.first_name, employee.last_name, employee.title_prefix, employee.title_suffix)}
</h2>
<StatusChip status={employee.status} entryDate={employee.entry_date} absenceType={employee.absence_type} />
<StatusChip employee={employee} asOf={today} />
</div>
<p className="text-sm text-ink-body">{employee.job_title}</p>
<p className="text-xs text-ink-muted">{breadcrumb}</p>
<p className="text-sm text-ink-body">{placement?.jobTitle ?? employee.job_title}</p>
<p className="text-xs text-ink-muted">
{breadcrumb}
{placement && (
<>
{" · Planstelle "}
{placement.positionNumber}
{placement.isChief && " (Leitung)"}
</>
)}
</p>
<p className="mt-1 text-xs text-ink-muted">
Pers.-Nr. {employee.personnel_number}
{employee.status !== "Geplant" && <> · Zugehörigkeit: {tenure(employee.entry_date, employee.exit_date)}</>}
{status !== "Geplant" && <> · Zugehörigkeit: {tenure(employee.entry_date, employee.exit_date)}</>}
</p>
</div>
</div>
@@ -95,25 +129,41 @@ export function EmployeeDetail(props: EmployeeDetailProps) {
<ActionButton icon={TrendingUp} label="Befördern" onClick={() => setPanel("promote")} />
<ActionButton
icon={Clock}
label={employee.status === "Karenz" ? "Abwesenheit verwalten" : "Langzeitabwesenheit"}
label={status === "Karenz" ? "Abwesenheit verwalten" : "Langzeitabwesenheit"}
onClick={() => setPanel("karenz")}
/>
</>
)}
{canEditData && <ActionButton icon={Pencil} label="Daten ändern" onClick={() => setPanel("daten")} />}
{isActive && (
{/* Auch bei einem geplanten Eintritt, und dort heisst es anders:
wer nie angetreten ist, „tritt" nicht „aus". Die Person hat
noch keinen Tag gearbeitet, und genau dafür gibt es den Grund
„No Show" — ohne diesen Knopf bliebe sie auf Dauer als
geplanter Eintritt stehen. */}
{(isActive || status === "Geplant") && (
<Button
variant="secondary"
size="sm"
onClick={() => setPanel("terminate")}
className="!border-danger-solid !text-danger-solid hover:!bg-danger-bg"
>
<XCircle className="h-4 w-4" /> Austritt
<XCircle className="h-4 w-4" />
{status === "Geplant" ? "Nicht angetreten" : "Austritt"}
</Button>
)}
{employee.status === "Ausgetreten" && (
{/* Der Knopf hing an `employee.status` — der Spalte, die
nachhängt. An einer Person, deren Austritt erfasst und
inzwischen vollzogen war, stand dort weiter „Aktiv", und der
Wiedereintritt war schlicht nicht erreichbar. Der Kunde hat
ihn deshalb für verschwunden gehalten („ich dachte, das ist
schon implementiert, das war mal drin").
*
Beim Statusfix waren nur `isActive` und `canEditData`
umgestellt worden — die fünf einzelnen Abfragen in dieser
Datei blieben stehen. Jetzt liest keine mehr die Spalte. */}
{status === "Ausgetreten" && (
<Button size="sm" onClick={() => setPanel("rehire")}>
<RotateCcw className="h-4 w-4" /> Wiedereinstellen
<RotateCcw className="h-4 w-4" /> Wiedereintritt
</Button>
)}
</div>
@@ -123,7 +173,7 @@ export function EmployeeDetail(props: EmployeeDetailProps) {
{/* Tabs, so the list gets the tablist role and each button says
whether it is the selected one. */}
<div role="tablist" aria-label="Mitarbeiterdetails" className="flex gap-1 overflow-x-auto border-b border-border">
{TABS.map((t) => (
{tabs.map((t) => (
<button
key={t}
role="tab"
@@ -133,7 +183,13 @@ export function EmployeeDetail(props: EmployeeDetailProps) {
tab === t ? "border-brand-500 text-brand-700" : "border-transparent text-ink-muted hover:text-ink"
}`}
>
{t === "HR-Notizen" ? `HR-Notizen ${notes.length}` : t}
{t === "HR-Notizen"
? `HR-Notizen ${notes.length}`
: t === "Onboarding" && offeneOnboarding > 0
? `Onboarding ${offeneOnboarding}`
: t === "Offboarding" && offeneOffboarding > 0
? `Offboarding ${offeneOffboarding}`
: t}
</button>
))}
</div>
@@ -142,32 +198,91 @@ export function EmployeeDetail(props: EmployeeDetailProps) {
{tab === "Stammdaten" && <StammdatenTab employee={employee} location={location} dependents={dependents} />}
{tab === "Vertrag" && <VertragTab employee={employee} />}
{tab === "Organisation" && (
<OrganisationTab employeeId={employee.id} manager={manager} directReports={directReports} breadcrumb={breadcrumb} />
<OrganisationTab
employeeId={employee.id}
manager={manager}
formalManager={formalManager}
directReports={directReports}
breadcrumb={breadcrumb}
kostenstelle={kostenstelle}
/>
)}
{tab === "Historie" && <HistorieTab history={history} />}
{tab === "Onboarding" && (
<OnboardingTab employeeId={employee.id} staende={onboarding} vorhanden={onboarding.length > 0} />
)}
{tab === "Offboarding" && zeigtOffboarding && (
<OffboardingTab employeeId={employee.id} staende={offboarding} vorhanden={offboarding.length > 0} />
)}
{tab === "Historie" && <HistorieTab history={history} employeeId={employee.id} />}
{tab === "HR-Notizen" && <NotizenTab employeeId={employee.id} notes={notes} />}
</div>
{/* Der `key` an jedem Panel ist kein Feinschliff, sondern der Unterschied
zwischen „zeigt Altes" und „schreibt Altes zurück".
Die Panels bleiben eingebunden, damit ihr Ein- und Ausfahren laufen
kann. Sie belegen ihre Felder aber mit useState(employee.…) vor, und
das läuft nur beim ersten Aufbau. Nach einer Beförderung bringt
router.refresh() zwar die frische Akte herein — der Zustand im Panel
bleibt der von vorhin. Beim nächsten Speichern geht er als Ganzes an
change_employee_data, und der eben gesetzte Hay-Grade steht wieder
auf dem alten Wert. Gemeldet im Test vom 29.09. (H.05).
employees.updated_at wechselt bei jeder Änderung an der Zeile
(Trigger trg_employees_touch_updated_at), also genau dann, wenn die
Vorbelegung neu zu lesen ist — und sonst nie. Der Wiedereintritts-
Assistent darunter macht es seit jeher so. */}
<TransferPanel
key={`transfer-${employee.updated_at}`}
open={panel === "transfer"}
onClose={() => setPanel(null)}
employee={employee}
divisions={divisions}
departments={departments}
teams={teams}
currentTeamId={employee.team_id}
openPositions={openPositions}
/>
<PromotePanel
key={`promote-${employee.updated_at}`}
open={panel === "promote"}
onClose={() => setPanel(null)}
employee={employee}
openPositions={openPositions}
/>
<KarenzPanel
key={`karenz-${employee.updated_at}`}
open={panel === "karenz"}
onClose={() => setPanel(null)}
employee={employee}
status={status}
/>
<PromotePanel open={panel === "promote"} onClose={() => setPanel(null)} employee={employee} />
<KarenzPanel open={panel === "karenz"} onClose={() => setPanel(null)} employee={employee} />
<DatenAendernPanel
key={`daten-${employee.updated_at}`}
open={panel === "daten"}
onClose={() => setPanel(null)}
employee={employee}
dependents={dependents}
locationCountry={location?.country}
/>
<TerminatePanel open={panel === "terminate"} onClose={() => setPanel(null)} employee={employee} directReportCount={directReports.length} />
<RehirePanel open={panel === "rehire"} onClose={() => setPanel(null)} employee={employee} />
<TerminatePanel
key={`terminate-${employee.updated_at}`}
open={panel === "terminate"}
onClose={() => setPanel(null)}
employee={employee}
status={status}
directReportCount={directReports.length}
/>
{/* Der `key` sorgt fürs Zurücksetzen: beim Öffnen entsteht der
Assistent neu und liest die Vorbelegung frisch aus der Akte. Ohne
ihn trüge er nach einem Abbruch die halb ausgefüllten Angaben des
vorigen Anlaufs. */}
{panel === "rehire" && (
<RehireWizard
key={employee.updated_at}
open
onClose={() => setPanel(null)}
employee={employee}
openPositions={openPositions}
locations={locations}
/>
)}
</div>
);
}

View File

@@ -6,7 +6,9 @@ import { FILTER_SELECT_CLASS } from "@/components/ui/Field";
import { SearchInput } from "@/components/ui/SearchInput";
type EmployeeFiltersProps = {
divisions: { id: string; name: string }[];
/** Der ganze Baum, in Tiefensuche-Reihenfolge. */
units: { id: string; name: string; unit_type: string }[];
depthOf: Map<string, number>;
locations: { id: string; name: string }[];
};
@@ -17,12 +19,16 @@ type EmployeeFiltersProps = {
const STATUS_OPTIONS = [
{ value: "Aktiv", label: "Aktiv" },
{ value: "Karenz", label: "Langzeitabwesenheit" },
{ value: "Aktiv,Karenz", label: "Aktiv + Langzeitabwesenheit (beschäftigt)" },
// Der Name der Kachel zuerst, die Bestandteile in Klammern dahinter: die
// Kachel „Aktives Dienstverhältnis" verlinkt genau auf diese Auswahl, und
// wer ihr folgt, soll oben dieselbe Bezeichnung wiederfinden statt eine
// zweite für dieselbe Sache.
{ value: "Aktiv,Karenz", label: "Aktives Dienstverhältnis (Aktiv + Langzeitabwesenheit)" },
{ value: "Geplant", label: "Geplant" },
{ value: "Ausgetreten", label: "Ausgetreten" },
] as const;
export function EmployeeFilters({ divisions, locations }: EmployeeFiltersProps) {
export function EmployeeFilters({ units, depthOf, locations }: EmployeeFiltersProps) {
const router = useRouter();
const pathname = usePathname();
const searchParams = useSearchParams();
@@ -55,18 +61,26 @@ export function EmployeeFilters({ divisions, locations }: EmployeeFiltersProps)
{/* aria-label rather than a visible label: the filter bar is a single
horizontal row, and each select's first option already names it on
screen. */}
{/* Der ganze Baum, nicht nur die oberste Ebene: die Auswahl greift
jeweils auf die Einheit *und alles darunter*, weshalb sich damit
auch nach einer einzelnen Abteilung oder einem Team filtern lässt.
Eingerückt statt gruppiert, weil optgroup keine Verschachtelung
kennt und die Tiefe hier beliebig ist. */}
<select
aria-label="Nach Bereich filtern"
aria-label="Nach Organisationseinheit filtern"
defaultValue={searchParams.get("division") ?? ""}
onChange={(e) => updateParam("division", e.target.value)}
className={FILTER_SELECT_CLASS}
>
<option value="">Alle Bereiche</option>
{divisions.map((d) => (
<option key={d.id} value={d.id}>
{d.name}
</option>
))}
<option value="">Alle Einheiten</option>
{units
.filter((u) => u.unit_type !== "Gesellschaft")
.map((u) => (
<option key={u.id} value={u.id}>
{" ".repeat(Math.max(0, (depthOf.get(u.id) ?? 1) - 1) * 3)}
{u.name}
</option>
))}
</select>
<select
aria-label="Nach Status filtern"
@@ -94,6 +108,15 @@ export function EmployeeFilters({ divisions, locations }: EmployeeFiltersProps)
</option>
))}
</select>
{/* Sortiert wird nicht hier, sondern an den Spaltenköpfen der Liste.
Diese Leiste schränkt ein, *was* zu sehen ist; die Reihenfolge
gehört an die Spalte, die sie bestimmt. */}
{/* Der Dienstwagen stand hier einmal als eigenes Auswahlfeld. Er ist
jetzt eines von rund zwanzig Kriterien unter Berichte, zusammen mit
Vertragsart, Kollektivvertrag, Eintrittszeitraum und dem Rest —
dort lässt sich die Auswahl auch exportieren, was der eigentliche
Zweck der Frage war. In dieser Leiste, die vor allem zum Suchen da
ist, wäre er ein Sonderfall unter vielen gleichrangigen. */}
</div>
);
}

View File

@@ -0,0 +1,234 @@
"use client";
import { Pencil } from "lucide-react";
import { useRouter } from "next/navigation";
import { useState } from "react";
import { updateHistoryEntry } from "@/actions/employees";
import { Button } from "@/components/ui/Button";
import { TextField } from "@/components/ui/Field";
import { Modal } from "@/components/ui/Modal";
import { useToast } from "@/components/ui/Toast";
import { fmtDate } from "@/lib/format";
import { auswahlFuer } from "@/lib/historie-felder";
import type { AuditChange } from "@/lib/types";
// Berichtigen, nicht neu erfassen.
//
// „Daten ändern" schreibt eine *neue* Änderung — richtig, wenn sich etwas
// wirklich geändert hat. Hier geht es um den anderen Fall: der Vorgang
// stimmt, aber der erfasste Wert oder das Datum nicht. Ohne diesen Weg
// stünden in der Akte zwei Einträge für eine Änderung, von denen der erste
// nie stattgefunden hat.
//
// Bearbeitet wird nur das **Nachher**. Das Vorher steht daneben, unveränder-
// lich: es beschreibt, was vor der Änderung galt, und das lässt sich
// nachträglich nicht anders beschliessen.
export function HistorieBearbeiten({
historyId,
employeeId,
bezeichnung,
datum,
changes,
istZukunft,
heute,
nurDatum = false,
}: {
historyId: string;
employeeId: string;
bezeichnung: string;
datum: string;
changes: AuditChange[];
/** Noch nicht wirksam — dann wird der geplante Vorgang berichtigt, nicht der Stand. */
istZukunft: boolean;
/** Vom Server, nicht aus new Date(): sonst rechnet der Browser mit seiner
* eigenen Zeitzone, und in einer Renderfunktion hat die Uhr ohnehin nichts
* verloren. */
heute: string;
/**
* Der Eintritt hat keine Felder, die sich zurücknehmen liessen — nur ein
* Datum, das falsch erfasst sein kann. Daran hängt trotzdem einiges: die
* erste Planstellenbesetzung, der frühestmögliche Zeitpunkt jedes weiteren
* Ereignisses, die Zugehörigkeit. Die Datenbank prüft das und weist
* verständlich ab.
*/
nurDatum?: boolean;
}) {
const [offen, setOffen] = useState(false);
const [laeuft, setLaeuft] = useState(false);
const [neuesDatum, setNeuesDatum] = useState(datum);
const [werte, setWerte] = useState<Record<string, string>>(() =>
Object.fromEntries(changes.map((c) => [c.feld, c.nachher ?? ""]))
);
const { showToast } = useToast();
const router = useRouter();
// Morgen aus dem Serverdatum, nicht aus der Uhr des Browsers.
const morgen = new Date(Date.parse(heute + "T00:00:00Z") + 86400000).toISOString().slice(0, 10);
const etwasGeaendert =
neuesDatum !== datum || changes.some((c) => (werte[c.feld] ?? "") !== (c.nachher ?? ""));
function abbrechen() {
// Beim Schliessen zurück auf den gespeicherten Stand, damit ein zweites
// Öffnen nicht die verworfenen Eingaben zeigt.
setNeuesDatum(datum);
setWerte(Object.fromEntries(changes.map((c) => [c.feld, c.nachher ?? ""])));
setOffen(false);
}
async function speichern() {
// Ein Eintrag bleibt auf seiner Seite der Gegenwart. Eine gelaufene
// Änderung in eine geplante zu verwandeln (oder umgekehrt) hiesse,
// Stammdaten und Vorgang gegenläufig anzupassen — dafür gibt es die
// fachlichen Vorgänge. Die Datenbank weist es ohnehin ab; hier steht es
// nur früher und freundlicher.
// Beim Eintritt gilt das nicht: er darf in der Vergangenheit *und* in der
// Zukunft liegen — ein geplanter Eintritt ist ein gewöhnlicher Fall. Was
// dort zusammenpassen muss, prüft die Datenbank und sagt es verständlich.
if (!nurDatum && istZukunft && neuesDatum <= heute) {
showToast("Eine geplante Änderung lässt sich hier nicht vorziehen.", "error");
return;
}
if (!nurDatum && !istZukunft && neuesDatum > heute) {
showToast("Eine bereits wirksame Änderung lässt sich nicht in die Zukunft verschieben.", "error");
return;
}
setLaeuft(true);
const ergebnis = await updateHistoryEntry({
history_id: historyId,
employee_id: employeeId,
event_date: neuesDatum,
werte: changes.map((c) => ({ feld: c.feld, nachher: werte[c.feld]?.trim() || null })),
});
setLaeuft(false);
if (ergebnis.success) {
showToast("Eintrag berichtigt.");
setOffen(false);
router.refresh();
} else {
showToast(ergebnis.error ?? "Berichtigen fehlgeschlagen.", "error");
}
}
return (
<>
<button
type="button"
onClick={() => setOffen(true)}
aria-label={`${bezeichnung} vom ${fmtDate(datum)} bearbeiten`}
className="rounded p-1 text-ink-muted hover:bg-brand-50 hover:text-brand-700
focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500"
>
<Pencil className="h-3.5 w-3.5" />
</button>
<Modal
open={offen}
onClose={abbrechen}
title="Eintrag berichtigen"
widthClassName="max-w-2xl"
footer={
<>
<Button variant="ghost" onClick={abbrechen}>
Abbrechen
</Button>
<Button onClick={speichern} pending={laeuft} disabled={!etwasGeaendert}>
Berichtigen
</Button>
</>
}
>
<p className="text-sm text-ink-body">
<strong className="text-ink">{bezeichnung}</strong>
{nurDatum
? " — der Eintritt selbst bleibt; berichtigt wird nur sein Datum."
: istZukunft
? " — diese Änderung ist noch nicht wirksam. Berichtigt wird, was am Stichtag passieren soll."
: " — was hier stand, war falsch erfasst. Für eine tatsächliche Änderung ist „Daten ändern“ der richtige Weg."}
</p>
<div className="mt-4 max-w-xs">
<TextField
label={nurDatum ? "Eintrittsdatum" : "Wirksam ab"}
type="date"
min={!nurDatum && istZukunft ? morgen : undefined}
max={!nurDatum && !istZukunft ? heute : undefined}
value={neuesDatum}
onChange={setNeuesDatum}
/>
</div>
{nurDatum && (
<p className="mt-4 rounded bg-surface px-3 py-2 text-xs text-ink-muted">
Daran hängt mehr als eine Zahl: die erste Planstellenbesetzung wandert mit, und kein anderes Ereignis darf
vor dem Eintritt liegen. Passt das neue Datum nicht dazu, wird die Änderung mit dem Grund abgewiesen.
</p>
)}
<div className={`mt-5 overflow-x-auto ${nurDatum ? "hidden" : ""}`}>
<table className="w-full text-sm">
<thead>
<tr className="border-b border-border text-left text-[11px] font-bold uppercase tracking-wider text-ink-muted">
<th className="py-2 pr-4">Feld</th>
<th className="py-2 pr-4">Vorher</th>
<th className="py-2">Nachher</th>
</tr>
</thead>
<tbody>
{changes.map((c) => (
<tr key={c.feld} className="border-b border-border-subtle align-middle last:border-0">
<td className="py-2 pr-4 font-semibold text-ink-body">{c.feld}</td>
<td className="py-2 pr-4 text-ink-muted">
{c.vorher === null || c.vorher === "" ? <span className="italic">leer</span> : c.vorher}
</td>
<td className="py-2">
{/* Führt das Feld eine feste Liste, wird sie auch hier
angeboten: getippt entstünde sonst ein Wert, den keine
Auswertung mehr findet — die Berichtigung schreibt in
dieselbe Spalte wie das Formular, nur ohne dessen
Prüfung. Welche Felder das sind, steht in
lib/historie-felder.ts. */}
{auswahlFuer(c.feld) ? (
<select
aria-label={`${c.feld} — neuer Wert`}
value={werte[c.feld] ?? ""}
onChange={(e) => setWerte((v) => ({ ...v, [c.feld]: e.target.value }))}
className="w-full rounded border border-border bg-white px-2 py-1 text-sm text-ink
focus-visible:outline-2 focus-visible:outline-offset-1 focus-visible:outline-brand-500"
>
<option value="">leer</option>
{auswahlFuer(c.feld)!.map((w) => (
<option key={w} value={w}>
{w}
</option>
))}
</select>
) : (
<input
type="text"
aria-label={`${c.feld} — neuer Wert`}
value={werte[c.feld] ?? ""}
onChange={(e) => setWerte((v) => ({ ...v, [c.feld]: e.target.value }))}
className="w-full rounded border border-border px-2 py-1 text-sm text-ink
focus-visible:outline-2 focus-visible:outline-offset-1 focus-visible:outline-brand-500"
/>
)}
</td>
</tr>
))}
</tbody>
</table>
</div>
<p className="mt-4 rounded bg-surface px-3 py-2 text-xs text-ink-muted">
{nurDatum
? "Stammdaten, Historie und Planstellenbesetzung werden gemeinsam nachgezogen."
: istZukunft
? "An den Stammdaten ändert sich jetzt nichts — die Änderung greift erst am Stichtag. Berichtigt wird der geplante Vorgang selbst."
: "Die Stammdaten werden nachgezogen — je Feld gilt dann der jüngste Eintrag, der es trägt. Hat eine spätere Änderung dasselbe Feld erneut gesetzt, bleibt deren Wert stehen."}{" "}
Die Berichtigung selbst steht im Protokoll.
</p>
</Modal>
</>
);
}

View File

@@ -0,0 +1,162 @@
"use client";
import { Trash2 } from "lucide-react";
import { useRouter } from "next/navigation";
import { useState } from "react";
import { deleteHistoryEntry } from "@/actions/employees";
import { Button } from "@/components/ui/Button";
import { Modal } from "@/components/ui/Modal";
import { useToast } from "@/components/ui/Toast";
import { fmtDate } from "@/lib/format";
import type { Vorschau } from "@/lib/history";
// Löschen mit Ansage.
//
// Bestätigen heisst hier nicht „Wirklich?" — das beantwortet jede Person nach
// dem dritten Mal blind mit Ja. Der Dialog sagt stattdessen, **was danach
// anders ist**: welches Feld auf welchen Wert zurückgeht, und welches nicht,
// weil eine spätere Änderung es erneut angefasst hat. Wer das liest, merkt
// selbst, ob er den richtigen Eintrag erwischt hat.
export function HistorieLoeschen({
historyId,
employeeId,
bezeichnung,
datum,
vorschau,
istZukunft,
}: {
historyId: string;
employeeId: string;
bezeichnung: string;
datum: string;
vorschau: Vorschau[];
/** Noch nicht wirksam — dann wird der geplante Vorgang entschärft. */
istZukunft: boolean;
}) {
const [offen, setOffen] = useState(false);
const [laeuft, setLaeuft] = useState(false);
const { showToast } = useToast();
const router = useRouter();
const zurueck = vorschau.filter((v) => !v.bleibt);
const bleibt = vorschau.filter((v) => v.bleibt);
// Eine geplante Abwesenheit oder Rückkehr hat keine einzelnen Felder, die
// sich herausnehmen liessen — sie fällt als Ganzes. Dann ist „Löschen und
// zurücksetzen" das falsche Wort für das, was der Knopf tut.
const ganzerVorgang = istZukunft && vorschau.length === 0;
async function loeschen() {
setLaeuft(true);
const ergebnis = await deleteHistoryEntry({ history_id: historyId, employee_id: employeeId });
setLaeuft(false);
if (ergebnis.success) {
showToast("Eintrag gelöscht.");
setOffen(false);
router.refresh();
} else {
showToast(ergebnis.error ?? "Löschen fehlgeschlagen.", "error");
}
}
return (
<>
<button
type="button"
onClick={() => setOffen(true)}
aria-label={`${bezeichnung} vom ${fmtDate(datum)} löschen`}
className="rounded p-1 text-ink-muted hover:bg-danger-bg hover:text-danger-text
focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500"
>
<Trash2 className="h-3.5 w-3.5" />
</button>
<Modal
open={offen}
onClose={() => setOffen(false)}
title={ganzerVorgang ? "Geplanten Vorgang abbrechen" : "Eintrag löschen"}
footer={
<>
<Button variant="ghost" onClick={() => setOffen(false)}>
Abbrechen
</Button>
<Button onClick={loeschen} pending={laeuft} className="!bg-danger-solid text-white hover:brightness-110">
{ganzerVorgang ? "Vorgang abbrechen" : "Löschen und zurücksetzen"}
</Button>
</>
}
>
<p className="text-sm text-ink-body">
<strong className="text-ink">{bezeichnung}</strong> {istZukunft ? "zum" : "vom"} {fmtDate(datum)} wird aus der
Historie entfernt.
</p>
{ganzerVorgang && (
<div className="mt-4">
<h3 className="text-xs font-bold uppercase tracking-wide text-ink-muted">Wird nicht mehr passieren</h3>
<p className="mt-1.5 text-sm text-ink-body">
Der Vorgang entfällt ganz — die {bezeichnung} zum {fmtDate(datum)} findet nicht statt. Am Stammsatz wird
das vorgemerkte Datum mit entfernt.
</p>
<p className="mt-2 text-xs text-ink-muted">
An den heutigen Stammdaten ändert sich nichts: der Vorgang war noch nicht wirksam.
</p>
</div>
)}
{istZukunft && vorschau.length > 0 && (
<div className="mt-4">
<h3 className="text-xs font-bold uppercase tracking-wide text-ink-muted">Wird nicht mehr passieren</h3>
<ul className="mt-1.5 flex flex-col gap-1">
{vorschau.map((v) => (
<li key={v.feld} className="text-sm text-ink-body">
<span className="font-semibold text-ink">{v.feld}</span>{" "}
<span className="text-ink-muted">sollte auf</span> <span className="text-ink">{v.von || "leer"}</span>{" "}
<span className="text-ink-muted">gesetzt werden</span>
</li>
))}
</ul>
<p className="mt-2 text-xs text-ink-muted">
An den Stammdaten ändert sich nichts — die Änderung war noch nicht wirksam. Betrifft der geplante Vorgang
noch weitere Felder, läuft er mit diesen weiter.
</p>
</div>
)}
{!istZukunft && zurueck.length > 0 && (
<div className="mt-4">
<h3 className="text-xs font-bold uppercase tracking-wide text-ink-muted">Wird zurückgesetzt</h3>
<ul className="mt-1.5 flex flex-col gap-1">
{zurueck.map((v) => (
<li key={v.feld} className="text-sm text-ink-body">
<span className="font-semibold text-ink">{v.feld}</span>{" "}
<span className="text-ink-muted line-through decoration-ink-muted/40">{v.von || "leer"}</span>{" "}
<span aria-hidden="true">→</span> <span className="text-ink">{v.auf || "leer"}</span>
</li>
))}
</ul>
</div>
)}
{!istZukunft && bleibt.length > 0 && (
<div className="mt-4">
<h3 className="text-xs font-bold uppercase tracking-wide text-ink-muted">Bleibt unverändert</h3>
<ul className="mt-1.5 flex flex-col gap-1">
{bleibt.map((v) => (
<li key={v.feld} className="text-sm text-ink-muted">
<span className="font-semibold">{v.feld}</span> — eine spätere Änderung hat dieses Feld erneut
gesetzt, und die gilt weiter.
</li>
))}
</ul>
</div>
)}
<p className="mt-4 rounded bg-surface px-3 py-2 text-xs text-ink-muted">
Der Vorgang wird im Protokoll festgehalten — mit Zeitpunkt, Person und den Werten der gelöschten Zeile. Die
Zeile selbst lässt sich nicht wiederherstellen.
</p>
</Modal>
</>
);
}

View File

@@ -0,0 +1,118 @@
"use client";
import { useRouter } from "next/navigation";
import { useState } from "react";
import { changeEmployeeData } from "@/actions/employees";
import { Button } from "@/components/ui/Button";
import { SelectField, TextField } from "@/components/ui/Field";
import { Modal } from "@/components/ui/Modal";
import { useToast } from "@/components/ui/Toast";
import { todayIso } from "@/lib/format";
import { EMERGENCY_RELATIONS } from "@/lib/types";
// Der Notfallkontakt, ohne den Umweg über „Daten ändern".
//
// Geschrieben wird über dieselbe Funktion wie dort: change_employee_data mit
// **nur** den drei Feldern im Abschnitt `person`. Das ist keine Abkürzung,
// sondern die Bedingung dafür, dass der Eintrag in der Historie und im
// Protokoll landet wie jede andere Stammdatenänderung. Die Datenbank fasst
// ausschliesslich die Felder an, die im Aufruf stehen — sie prüft auf das
// Vorhandensein des Schlüssels, nicht auf seinen Wert (Migration
// 20260917120000). Adresse, E-Mail und der Rest bleiben deshalb unberührt.
export type Notfallkontakt = {
name: string | null;
telefon: string | null;
verhaeltnis: string | null;
};
export function NotfallkontaktModal({
open,
onClose,
employeeId,
kontakt,
effectiveDate,
}: {
open: boolean;
onClose: () => void;
employeeId: string;
kontakt: Notfallkontakt;
/** Aus „Daten ändern"; ohne Angabe gilt heute. */
effectiveDate?: string;
}) {
const { showToast } = useToast();
const router = useRouter();
const [name, setName] = useState(kontakt.name ?? "");
const [telefon, setTelefon] = useState(kontakt.telefon ?? "");
const [verhaeltnis, setVerhaeltnis] = useState(kontakt.verhaeltnis ?? "");
const [pending, setPending] = useState(false);
const vorhanden = Boolean(kontakt.name);
async function handleSubmit() {
// Name und Telefonnummer gehören zusammen: ein Name ohne Nummer hilft im
// Ernstfall niemandem, eine Nummer ohne Namen sagt nicht, wen man dran
// hat.
if (!name.trim() || !telefon.trim()) {
showToast("Name und Telefonnummer sind nötig.", "error");
return;
}
setPending(true);
const result = await changeEmployeeData({
employee_id: employeeId,
effective_date: effectiveDate || todayIso(),
person: {
emergency_contact_name: name.trim(),
emergency_contact_phone: telefon.trim(),
emergency_contact_relation: verhaeltnis.trim(),
},
contract: {},
role: {},
});
setPending(false);
if (result.success) {
showToast(vorhanden ? "Notfallkontakt geändert." : "Notfallkontakt hinterlegt.");
router.refresh();
onClose();
} else {
showToast(result.error ?? "Fehler beim Speichern.", "error");
}
}
return (
<Modal
open={open}
onClose={onClose}
title={vorhanden ? "Notfallkontakt ändern" : "Notfallkontakt hinterlegen"}
footer={
<>
<Button variant="ghost" onClick={onClose}>
Abbrechen
</Button>
<Button onClick={handleSubmit} pending={pending}>
Speichern
</Button>
</>
}
>
{/* Kein „Wirksam ab": ein Notfallkontakt gilt ab sofort. Das Feld stand
hier, weil die Datenbankfunktion einen Stichtag kennt — bei einer
Telefonnummer, die im Ernstfall gewählt wird, ist ein Datum in der
Zukunft keine sinnvolle Angabe, sondern eine Frage zu viel. */}
<div className="flex flex-col gap-4">
<TextField label="Name" required value={name} onChange={setName} />
<TextField label="Telefonnummer" required type="tel" value={telefon} onChange={setTelefon} />
{/* Dieselbe Liste wie im Einstellungsassistenten (EMERGENCY_RELATIONS)
und kein Freitext: sonst stünden „Gattin", „Ehefrau" und „Frau"
nebeneinander und liessen sich nicht auswerten. */}
<SelectField
label="Verhältnis"
value={verhaeltnis}
onChange={setVerhaeltnis}
placeholder="Bitte wählen…"
options={EMERGENCY_RELATIONS.map((r) => ({ value: r, label: r }))}
/>
</div>
</Modal>
);
}

View File

@@ -0,0 +1,156 @@
"use client";
import { Pencil, Plus, Trash2 } from "lucide-react";
import { useRouter } from "next/navigation";
import { useState } from "react";
import { changeEmployeeData } from "@/actions/employees";
import { Button } from "@/components/ui/Button";
import { useToast } from "@/components/ui/Toast";
import { todayIso } from "@/lib/format";
import { NotfallkontaktModal, type Notfallkontakt } from "./NotfallkontaktModal";
// Eigener Abschnitt statt einer Zelle im Raster, und unterhalb der
// Angehörigen: beides sind Personen im Umfeld, und der Notfallkontakt ist die
// Ausnahme davon — deshalb steht er zuletzt, nicht dazwischen. Im Ernstfall
// greift jemand in Eile danach; dann muss die Nummer sofort zu finden sein
// und wählbar.
//
// Der Knopf steht hier, weil er bei den Angehörigen darüber auch steht. Ohne
// ihn führte der einzige Weg über „Daten ändern" — ein Formular über alle
// Stammdaten, um eine Telefonnummer einzutragen.
export function NotfallkontaktSection({
employeeId,
kontakt,
effectiveDate,
}: {
employeeId: string;
kontakt: Notfallkontakt;
/**
* Nur, wenn der Abschnitt in „Daten ändern" steht: dann treibt dessen
* „Wirksam ab" auch diesen Vorgang — wie bei den Angehörigen darüber.
* Ohne Angabe gilt heute.
*/
effectiveDate?: string;
}) {
const { showToast } = useToast();
const router = useRouter();
const [modalOpen, setModalOpen] = useState(false);
const [entfernt, setEntfernt] = useState(false);
const stichtag = effectiveDate || todayIso();
const vorhanden = Boolean(kontakt.name);
async function handleEntfernen() {
setEntfernt(true);
// Leere Zeichenketten, nicht ausgelassene Felder: die Datenbank macht
// daraus null. Würden die Schlüssel fehlen, bliebe der Kontakt stehen.
const result = await changeEmployeeData({
employee_id: employeeId,
effective_date: stichtag,
person: { emergency_contact_name: "", emergency_contact_phone: "", emergency_contact_relation: "" },
contract: {},
role: {},
});
setEntfernt(false);
if (result.success) {
showToast("Notfallkontakt entfernt.");
router.refresh();
} else {
showToast(result.error ?? "Fehler beim Entfernen.", "error");
}
}
return (
<div className="border-t border-border pt-6">
<div className="mb-3 flex items-center justify-between">
<h3 className="text-xs font-bold uppercase tracking-wide text-brand-700">Notfallkontakt</h3>
{/* Nur, solange keiner hinterlegt ist: es gibt genau einen. Ein
zweites „Hinzufügen" daneben verspräche eine Liste, die es hier
nicht gibt — geändert und entfernt wird in der Zeile selbst. */}
{!vorhanden && (
<Button
variant="ghost"
size="sm"
onClick={() => setModalOpen(true)}
className="!px-1 text-brand-700 hover:!bg-transparent hover:underline"
>
<Plus className="h-3.5 w-3.5" /> Hinzufügen
</Button>
)}
</div>
{/* Dieselbe Tabelle wie bei den Angehörigen darüber, Zeile für Zeile
derselbe Aufbau. Vorher stand hier eine Beschreibungsliste — fachlich
dasselbe, optisch ein zweiter Baustil im selben Reiter. Zwei Listen
von Personen im Umfeld sollen gleich aussehen. */}
{vorhanden ? (
<div className="overflow-x-auto rounded border border-border">
<table className="w-full min-w-[600px] text-sm">
<thead>
<tr className="border-b border-border bg-accent-50 text-left text-xs font-semibold uppercase tracking-wide text-ink-muted">
<th className="px-4 py-2.5">Name</th>
<th className="px-4 py-2.5">Telefon</th>
<th className="px-4 py-2.5">Verhältnis</th>
<th className="px-4 py-2.5" />
</tr>
</thead>
<tbody>
<tr className="border-b border-border last:border-0">
<td className="px-4 py-2.5 font-semibold text-ink">{kontakt.name}</td>
<td className="px-4 py-2.5 text-ink-body">
{kontakt.telefon ? (
// Wählbar: im Ernstfall greift jemand in Eile danach.
<a
href={`tel:${kontakt.telefon.replace(/\s/g, "")}`}
className="rounded font-semibold hover:text-brand-700 hover:underline
focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500"
>
{kontakt.telefon}
</a>
) : (
"–"
)}
</td>
<td className="px-4 py-2.5 text-ink-body">{kontakt.verhaeltnis || "–"}</td>
<td className="px-4 py-2.5 text-right">
<Button
variant="icon"
onClick={() => setModalOpen(true)}
aria-label="Notfallkontakt ändern"
className="hover:!text-brand-700"
>
<Pencil className="h-3.5 w-3.5" />
</Button>
<Button
variant="icon"
onClick={handleEntfernen}
pending={entfernt}
aria-label="Notfallkontakt entfernen"
className="hover:!text-danger-solid"
>
<Trash2 className="h-3.5 w-3.5" />
</Button>
</td>
</tr>
</tbody>
</table>
</div>
) : (
<p className="text-sm text-ink-muted">Kein Notfallkontakt hinterlegt.</p>
)}
{/* `key` setzt die Felder auf den gespeicherten Stand zurück, sobald
sich der Kontakt geändert hat — das Fenster bleibt sonst montiert
und zeigte beim zweiten Öffnen den alten Entwurf. */}
<NotfallkontaktModal
key={`${kontakt.name ?? ""}|${kontakt.telefon ?? ""}|${kontakt.verhaeltnis ?? ""}`}
open={modalOpen}
onClose={() => setModalOpen(false)}
employeeId={employeeId}
kontakt={kontakt}
effectiveDate={stichtag}
/>
</div>
);
}

View File

@@ -0,0 +1,195 @@
"use client";
import { Printer } from "lucide-react";
import { useEffect } from "react";
import { Button } from "@/components/ui/Button";
import {
alleReichungen,
fortschrittVon,
istErledigt,
type AufgabenGruppe,
type AufgabenStand,
} from "@/lib/checklist";
import { artTitel, checklistDateiname, type ChecklistArt } from "@/lib/checklist-print";
import type { ChecklistKopf } from "@/lib/checklist-print-data";
import { fmtDate, fmtName } from "@/lib/format";
// Der Ausdruck einer Checkliste — eine Seite, zum Abheften oder Mitnehmen.
//
// Warum überhaupt Papier, wenn die Liste in der Anwendung steht: sie wird
// besprochen. Beim Eintrittsgespräch liegt sie auf dem Tisch, beim Austritt
// geht sie an die Lohnverrechnung, und in einer Personalakte auf Papier fehlt
// sie sonst. Gedruckt wird deshalb der **Stand**, mit Datum des Auszugs — kein
// Formular zum Ausfüllen.
//
// Erzeugt wird kein PDF im Server: gedruckt wird über den Browser, wie beim
// Organigramm. Der Grund ist derselbe — eine PDF-Bibliothek müsste Schriften,
// Umbrüche und Seitenränder selbst nachbauen, und das Ergebnis wäre ein
// zweites Aussehen neben dem der Anwendung. Der Dateiname im Speichern-Dialog
// kommt aus dem Dokumenttitel; den setzt diese Seite auf die Konvention.
const GLYPH_AN = "☒";
const GLYPH_AUS = "☐";
export function PrintChecklist({
art,
kopf,
gruppen,
staende,
today,
}: {
art: ChecklistArt;
kopf: ChecklistKopf;
gruppen: readonly AufgabenGruppe[];
staende: AufgabenStand[];
/** Vom Server: das Auszugsdatum gehört nicht an die Uhr des Browsers. */
today: string;
}) {
const dateiname = checklistDateiname(art, kopf, today);
// Der Titel ist der Vorschlag im Druckdialog. Ohne ihn hiesse die Datei nach
// der Adresse der Seite, also etwa „employees-…-checkliste".
useEffect(() => {
const vorher = document.title;
document.title = dateiname;
return () => {
document.title = vorher;
};
}, [dateiname]);
const punkte = alleReichungen(gruppen);
const karte = new Map(staende.map((s) => [s.item_key, s]));
const stand = fortschrittVon(punkte, staende);
return (
<div className="flex flex-col gap-5">
<style>{`
@page { size: A4 portrait; margin: 14mm 14mm 12mm; }
@media print {
html, body { background: #fff; }
.nur-bildschirm { display: none !important; }
.blatt {
box-shadow: none !important; border: 0 !important; border-radius: 0 !important;
margin: 0 !important; padding: 0 !important; width: auto !important; min-height: 0 !important;
}
/* Eine Gruppe soll nicht mitten in der Überschrift umbrechen, und
eine Zeile nicht zwischen Haken und Kommentar. */
.gruppe { break-inside: avoid; }
.punkt { break-inside: avoid; }
}
/* Zweispaltig, damit 25 Punkte auf ein Blatt gehen. Als Spaltensatz und
nicht als Gitter: die Punkte fliessen dann von der linken in die
rechte Spalte, statt dass eine Spalte halb leer bleibt. */
.spalten { column-count: 2; column-gap: 10mm; }
`}</style>
<div className="nur-bildschirm flex flex-wrap items-center justify-between gap-3">
<p className="text-sm text-ink-muted">
So kommt es aus dem Drucker. Vorgeschlagener Dateiname:{" "}
<span className="font-semibold text-ink">{dateiname}.pdf</span>
</p>
<Button onClick={() => window.print()}>
<Printer className="h-4 w-4" />
Als PDF speichern
</Button>
</div>
<p className="nur-bildschirm max-w-prose text-xs leading-relaxed text-ink-muted">
Im Druckdialog &bdquo;Als PDF speichern&ldquo; wählen. Hintergrundgrafiken müssen dort eingeschaltet sein, sonst
fehlen die Flächen hinter den Gruppentiteln &mdash; in Chrome unter &bdquo;Weitere Einstellungen&ldquo;.
</p>
<div className="blatt mx-auto w-[210mm] rounded border border-border bg-white p-[14mm] shadow-[var(--shadow-card)]">
{/* ── Kopf ───────────────────────────────────────────── */}
<div className="flex items-start justify-between gap-6 border-b-2 border-ink pb-2">
<div>
<h1 className="text-[15pt] font-extrabold leading-tight text-ink">{artTitel(art)}</h1>
<p className="text-[9pt] text-ink-muted">Alpenwerk Industrie GmbH</p>
</div>
<p className="text-right text-[8pt] leading-snug text-ink-muted">
Auszug vom
<span className="block text-[10pt] font-semibold tabular-nums text-ink">{fmtDate(today)}</span>
</p>
</div>
<dl className="mt-3 grid grid-cols-[auto_1fr_auto_1fr] gap-x-4 gap-y-1 text-[9pt]">
<dt className="font-semibold text-ink-muted">Pers.-Nr.</dt>
<dd className="tabular-nums text-ink">{kopf.personnel_number}</dd>
<dt className="font-semibold text-ink-muted">Eintritt</dt>
<dd className="tabular-nums text-ink">{fmtDate(kopf.entry_date)}</dd>
<dt className="font-semibold text-ink-muted">Name</dt>
<dd className="font-semibold text-ink">{fmtName(kopf.first_name, kopf.last_name)}</dd>
<dt className="font-semibold text-ink-muted">Position</dt>
<dd className="text-ink">
{kopf.position_title ?? kopf.job_title}
{kopf.position_number && <span className="text-ink-muted"> · Planstelle {kopf.position_number}</span>}
</dd>
</dl>
{/* ── Fortschritt ────────────────────────────────────── */}
<div className="mt-3 flex items-baseline justify-between border-t border-border pt-2 text-[9pt]">
<span className="font-semibold text-ink">
{stand.erledigt} von {stand.gesamt} erledigt
</span>
{stand.offen.length > 0 && (
<span className="text-ink-muted">
{stand.offen.length} offen
</span>
)}
</div>
{/* ── Die Punkte ─────────────────────────────────────── */}
<div className="spalten mt-3">
{gruppen.map((gruppe) => (
<div key={gruppe.key} className="gruppe mb-3">
<h2 className="mb-1 bg-surface px-1.5 py-0.5 text-[8pt] font-bold uppercase tracking-wide text-ink-body">
{gruppe.label}
</h2>
<ul>
{gruppe.punkte.map((punkt) => {
const s = karte.get(punkt.key);
const fertig = istErledigt(punkt, s);
return (
<li key={punkt.key} className="punkt flex gap-1.5 py-[2pt] text-[9pt] leading-snug">
<span aria-hidden className="shrink-0 text-[10pt] leading-none text-ink">
{fertig ? GLYPH_AN : GLYPH_AUS}
</span>
<span className="min-w-0">
<span className={fertig ? "text-ink" : "text-ink-body"}>{punkt.label}</span>
{/* Bei Ja/Nein und Text steht der Wert daneben — ein
Haken allein sagte dort nicht, was erfasst wurde. */}
{punkt.art !== "haken" && (
<span className="font-semibold text-ink">
{": "}
{s?.wert ?? "—"}
</span>
)}
{s?.kommentar && (
<span className="block text-[8pt] italic text-ink-body">{s.kommentar}</span>
)}
{s?.updated_by_name && fertig && (
<span className="block text-[7pt] text-ink-muted">
{s.updated_by_name}
{s.updated_at ? ` · ${fmtDate(s.updated_at)}` : ""}
</span>
)}
</span>
</li>
);
})}
</ul>
</div>
))}
</div>
{/* Hier standen zwei Unterschriftenfelder — „Datum, Unterschrift
Mitarbeiter:in" und „… Personalabteilung". Der Kunde hat sie
gestrichen (Anforderung 3 aus dem Workshop): das Blatt ist eine
Arbeitsliste für die Personalabteilung und kein Dokument, das
jemand gegenzeichnet. Wer eine Aufgabe abgehakt hat, steht ohnehin
an der Aufgabe selbst. */}
</div>
</div>
);
}

View File

@@ -1,40 +1,146 @@
"use client";
import { SelectField } from "@/components/ui/Field";
import type { CollectiveAgreement, Weekday, WorkerType } from "@/lib/supabase/types";
import { SelectField, TextField } from "@/components/ui/Field";
import {
GRUND_BEGUENSTIGT_BEHINDERT,
KUENDIGUNGSSCHUTZ_GRUENDE,
} from "@/lib/kuendigungsschutz";
import { MITARBEITERARTEN } from "@/lib/mitarbeiterart";
import { sortiereWochentage, WOCHENTAGE } from "@/lib/wochentage";
import type { CollectiveAgreement, DienstwagenArt, Mitarbeiterart, SourceType, Weekday, WorkerType } from "@/lib/types";
const WEEKDAYS: Weekday[] = ["Mo", "Di", "Mi", "Do", "Fr", "Sa", "So"];
export type RoleEmploymentValue = {
workerType: WorkerType;
/**
* Form der Beschäftigung — zweite Achse neben der Gruppe. Ein Praktikant
* kann Arbeiter oder Angestellter sein; in einem Feld liesse sich nur eines
* von beidem sagen.
*/
mitarbeiterart: Mitarbeiterart;
/**
* Extern oder intern besetzt.
*
* Wurde bisher nur bei der Neueinstellung gesetzt und war danach
* unerreichbar — eine Angabe, die mit dem ersten Tag erstarrt, obwohl
* gerade ihr Wechsel der Vorgang ist, um den es geht: von extern auf
* intern ist eine **Übernahme** und wird als eigenes Ereignis protokolliert
* (Migration 20260917120000).
*
* Nicht gesetzt heisst: dieses Formular fragt die Besetzungsart nicht. So
* ist es im Einstellungsassistenten — dort steht sie im Schritt „Position",
* wo sie hingehört, und zweimal danach zu fragen wäre eine Einladung, zwei
* verschiedene Antworten zu geben.
*/
source?: SourceType;
collectiveAgreement: CollectiveAgreement;
workDays: Weekday[];
isBetriebsrat: boolean;
hasDienstwagen: boolean;
/**
* Nur bedeutsam, solange hasDienstwagen gesetzt ist.
*
* Der Wert bleibt beim Abwählen stehen, statt zurückgesetzt zu werden —
* wer versehentlich klickt und zurückklickt, findet seine Angabe wieder.
* Beim Speichern setzen die Aufrufer ihn auf null, wie es der CHECK
* verlangt.
*/
dienstwagenArt: DienstwagenArt;
isLateraleFuehrung: boolean;
isCLevel: boolean;
/** Betriebsrat, Mutterschutz, Karenz, begünstigte Behinderung, Lehre. */
hasKuendigungsschutz: boolean;
/**
* Ende des Schutzes — freiwillig. Bei einem Betriebsratsmandat steht es
* fest, bei einer Schwangerschaft nicht; ein Pflichtfeld zwänge dort zu
* einer erfundenen Zahl. Leer heisst „bis auf Weiteres".
*/
kuendigungsschutzBis: string;
/**
* Der Personenkreis — freiwillig, aus demselben Grund wie das Enddatum:
* der Bestand trägt das Kennzeichen seit 20260814120000 ohne Grund, und ein
* Pflichtfeld hätte jede Änderung an diesen Zeilen blockiert.
*/
kuendigungsschutzGrund: string;
/** Beginn des Schutzes — ebenfalls freiwillig. */
kuendigungsschutzAb: string;
/**
* Begünstigte Behinderung. Eigenes Kennzeichen und nicht aus dem
* Personenkreis abgeleitet: die Begünstigung besteht unabhängig davon, ob
* sie als Kündigungsschutz geführt wird. Die Oberfläche stellt den
* Zusammenhang her, die Datenbank koppelt die beiden nicht.
*/
istBeguenstigtBehindert: boolean;
/** Grad in Prozent laut Bescheid. Als Text, weil ein leeres Zahlenfeld sonst 0 wäre. */
behinderungGrad: string;
behinderungAb: string;
behinderungBis: string;
};
// Shared by the hire wizard (StepVertrag) and DatenAendernPanel — both edit
// the same set of employees columns, just against different local state.
export function RoleEmploymentFields({ value, onChange }: { value: RoleEmploymentValue; onChange: (patch: Partial<RoleEmploymentValue>) => void }) {
function toggleWorkDay(day: Weekday) {
onChange({ workDays: value.workDays.includes(day) ? value.workDays.filter((d) => d !== day) : [...value.workDays, day] });
// Sortiert und nicht angehängt: sonst hinge die gespeicherte Reihenfolge
// davon ab, in welcher die Knöpfe angeklickt wurden. „Mo, Di" und „Di,
// Mo" waren damit zwei Werte für dieselbe Aussage, und wer die Tage nur
// nachsah und wieder herstellte, erzeugte eine Vertragsänderung in der
// Akte über nichts. Siehe lib/wochentage.ts.
const neu = value.workDays.includes(day) ? value.workDays.filter((d) => d !== day) : [...value.workDays, day];
onChange({ workDays: sortiereWochentage(neu) });
}
// Der Personenkreis zieht das Kennzeichen mit: wer „Begünstigte behinderte
// ArbeitnehmerInnen" als Grund wählt, hat die Frage damit schon beantwortet.
// Eine Hilfe der Oberfläche, keine Bedingung der Datenbank — abwählen lässt
// es sich weiterhin.
const istBehindert = value.istBeguenstigtBehindert || value.kuendigungsschutzGrund === GRUND_BEGUENSTIGT_BEHINDERT;
return (
<div className="flex flex-col gap-3">
<div className="grid grid-cols-1 gap-3 sm:grid-cols-2">
{/* „Beschäftigtengruppe" statt „Angestellte:r / Arbeiter:in": ein
Feld, das nach seinen Werten heisst, wird falsch, sobald ein
dritter dazukommt. Den Namen führt der Import schon länger. */}
<SelectField
label="Angestellte:r / Arbeiter:in"
label="Beschäftigtengruppe"
dense
value={value.workerType}
onChange={(v) => onChange({ workerType: v as WorkerType })}
options={[
{ value: "Angestellte:r", label: "Angestellte:r" },
{ value: "Arbeiter:in", label: "Arbeiter:in" },
{ value: "Lehrling", label: "Lehrling" },
]}
/>
{/* Zweites Feld und nicht dieselbe Liste erweitert: die Gruppe sagt,
*als was* jemand beschäftigt ist, die Art *in welcher Form*. Beides
gilt gleichzeitig — ein Praktikant ist Arbeiter oder Angestellter,
nicht statt dessen. */}
<SelectField
label="Mitarbeiterart"
dense
value={value.mitarbeiterart}
onChange={(v) => onChange({ mitarbeiterart: v as Mitarbeiterart })}
options={MITARBEITERARTEN.map((a) => ({ value: a, label: a }))}
/>
{/* Der Wechsel von extern auf intern ist eine Übernahme und wird als
eigenes Ereignis protokolliert — der Hinweis steht am Feld, damit
niemand ihn erst im Protokoll entdeckt. Der umgekehrte Weg
erzeugt nichts; das ist Absicht und keine Lücke. */}
{value.source !== undefined && (
<SelectField
label="Besetzungsart"
dense
value={value.source}
onChange={(v) => onChange({ source: v as SourceType })}
options={[
{ value: "Extern", label: "Extern" },
{ value: "Intern", label: "Intern" },
]}
hint={value.source === "Extern" ? "Ein Wechsel auf „Intern“ wird als Übernahme protokolliert." : undefined}
/>
)}
<SelectField
label="Kollektivvertrag"
dense
@@ -53,7 +159,7 @@ export function RoleEmploymentFields({ value, onChange }: { value: RoleEmploymen
<fieldset>
<legend className="mb-1 block text-xs font-semibold text-ink-muted">Arbeitstage</legend>
<div className="flex flex-wrap gap-1.5">
{WEEKDAYS.map((day) => (
{WOCHENTAGE.map((day) => (
<button
key={day}
type="button"
@@ -78,6 +184,21 @@ export function RoleEmploymentFields({ value, onChange }: { value: RoleEmploymen
<input type="checkbox" checked={value.hasDienstwagen} onChange={(e) => onChange({ hasDienstwagen: e.target.checked })} />
Dienstwagen
</label>
{/* Nur sichtbar, wenn es einen gibt: eine Antriebsart ohne Fahrzeug
ist keine Angabe, sondern eine Frage ohne Gegenstand — und die
Datenbank weist sie ab. */}
{value.hasDienstwagen && (
<SelectField
label="Antriebsart"
dense
value={value.dienstwagenArt}
onChange={(v) => onChange({ dienstwagenArt: v as DienstwagenArt })}
options={[
{ value: "Verbrenner", label: "Verbrenner" },
{ value: "Elektro", label: "Elektro (E-KFZ)" },
]}
/>
)}
<label className="flex items-center gap-2 text-sm text-ink-body">
<input type="checkbox" checked={value.isLateraleFuehrung} onChange={(e) => onChange({ isLateraleFuehrung: e.target.checked })} />
Laterale Führung
@@ -86,6 +207,97 @@ export function RoleEmploymentFields({ value, onChange }: { value: RoleEmploymen
<input type="checkbox" checked={value.isCLevel} onChange={(e) => onChange({ isCLevel: e.target.checked })} />
C-Level
</label>
<label className="flex items-center gap-2 text-sm text-ink-body">
<input
type="checkbox"
checked={value.hasKuendigungsschutz}
onChange={(e) => onChange({ hasKuendigungsschutz: e.target.checked })}
/>
Besonderer Kündigungsschutz
</label>
{/* Wie bei der Antriebsart: erst sichtbar, wenn es einen Gegenstand
gibt. Anders als dort aber freiwillig — leer heisst „bis auf
Weiteres", nicht „vergessen". */}
{value.hasKuendigungsschutz && (
<>
<SelectField
label="Grund"
dense
value={value.kuendigungsschutzGrund}
onChange={(v) => onChange({ kuendigungsschutzGrund: v })}
options={[
{ value: "", label: "Nicht erfasst" },
...KUENDIGUNGSSCHUTZ_GRUENDE.map((g) => ({ value: g, label: g })),
]}
hint="Bestimmt, wer einer Beendigung zustimmen muss."
/>
<TextField
label="Geschützt ab"
dense
type="date"
value={value.kuendigungsschutzAb}
onChange={(v) => onChange({ kuendigungsschutzAb: v })}
hint="Optional."
/>
<TextField
label="Geschützt bis"
dense
type="date"
value={value.kuendigungsschutzBis}
onChange={(v) => onChange({ kuendigungsschutzBis: v })}
hint="Optional. Leer lassen, solange das Ende nicht feststeht."
/>
{/* ── Begünstigte Behinderung ────────────────────────────
Als Unterpunkt des Kündigungsschutzes und eingerückt — sie ist
einer der zwölf Personenkreise und stand vorher als eigener
Block daneben, was sie wie ein zweites, unabhängiges Thema
aussehen liess.
*
In der Datenbank bleibt sie trotzdem ein eigenes Kennzeichen
mit eigenen Feldern, und das mit Absicht: eine Bedingung
„Grad nur bei diesem Personenkreis" liesse jede Korrektur am
Personenkreis scheitern, solange der Grad noch dransteht —
also genau beim Geradebiegen eines Fehlers. Was hier
zusammengehört, muss dort nicht aneinandergekettet sein. */}
<div className="ml-1 flex flex-col gap-2 border-l-2 border-border-subtle pl-3">
<label className="flex items-center gap-2 text-sm text-ink-body">
<input
type="checkbox"
checked={istBehindert}
onChange={(e) => onChange({ istBeguenstigtBehindert: e.target.checked })}
/>
Begünstigt behindert
</label>
{istBehindert && (
<div className="grid grid-cols-1 gap-3 sm:grid-cols-2">
<TextField
label="Grad der Behinderung"
dense
type="number"
value={value.behinderungGrad}
onChange={(v) => onChange({ behinderungGrad: v })}
/>
<TextField
label="Bescheid ab"
dense
type="date"
value={value.behinderungAb}
onChange={(v) => onChange({ behinderungAb: v })}
/>
<TextField
label="Bescheid bis"
dense
type="date"
value={value.behinderungBis}
onChange={(v) => onChange({ behinderungBis: v })}
hint="Leer heisst unbefristet."
/>
</div>
)}
</div>
</>
)}
</div>
</div>
);

View File

@@ -12,10 +12,15 @@ import { CountryPicker } from "@/components/ui/CountryPicker";
import { Field, SelectField, TextField } from "@/components/ui/Field";
import { SlideOver } from "@/components/ui/SlideOver";
import { useToast } from "@/components/ui/Toast";
import { UN_COUNTRIES } from "@/lib/countries";
import { brauchtAufenthaltstitel, UN_COUNTRIES } from "@/lib/countries";
import { HAY_GRADES } from "@/lib/hay-grade";
import { STUNDEN_GRUENDE } from "@/lib/absence";
import { GRUND_BEGUENSTIGT_BEHINDERT } from "@/lib/kuendigungsschutz";
import { MITARBEITERART_STANDARD } from "@/lib/mitarbeiterart";
import { fmtFullName, todayIso } from "@/lib/format";
import { isValidSvnr, requiresAustrianSvnr } from "@/lib/svnr";
import type { ContractType, Database, EmploymentType, GenderType } from "@/lib/supabase/types";
import { NotfallkontaktSection } from "@/components/employees/NotfallkontaktSection";
import type { ContractType, Database, EmploymentType, GenderType, PaygradeType } from "@/lib/types";
type EmployeeRow = Database["public"]["Tables"]["employees"]["Row"];
type Dependent = Database["public"]["Tables"]["employee_dependents"]["Row"];
@@ -52,30 +57,63 @@ export function DatenAendernPanel({
const svNummerOk =
!svNummer.trim() || !requiresAustrianSvnr(locationCountry) || isValidSvnr(svNummer, birthDate || null);
const [nationality, setNationality] = useState(employee.nationality);
const [hatTitel, setHatTitel] = useState(employee.hat_aufenthaltstitel ?? false);
const [titelBis, setTitelBis] = useState(employee.aufenthaltstitel_bis ?? "");
// Die Staatsbürgerschaft entscheidet, ob die Frage überhaupt gestellt wird.
const titelNoetig = brauchtAufenthaltstitel(nationality);
const [address, setAddress] = useState(employee.address ?? "");
const [postalCode, setPostalCode] = useState(employee.postal_code ?? "");
const [city, setCity] = useState(employee.city ?? "");
const [addressCountry, setAddressCountry] = useState(employee.address_country ?? "Österreich");
const [email, setEmail] = useState(employee.email);
const [email, setEmail] = useState(employee.email ?? "");
const [companyEmail, setCompanyEmail] = useState(employee.company_email ?? "");
const [cornerstoneId, setCornerstoneId] = useState(employee.cornerstone_id ?? "");
const [phone, setPhone] = useState(employee.phone ?? "");
const [employmentType, setEmploymentType] = useState<EmploymentType>(employee.employment_type);
const [weeklyHours, setWeeklyHours] = useState(String(employee.weekly_hours));
// Der Grund wird erst gefragt, wenn sich die Stunden tatsächlich ändern —
// sonst stünde bei jeder Adressänderung eine Frage im Weg, die niemand
// gestellt hat.
const [stundenGrund, setStundenGrund] = useState<string>(STUNDEN_GRUENDE[0]);
const stundenGeaendert = Number(weeklyHours) !== Number(employee.weekly_hours);
const [teilzeitBis, setTeilzeitBis] = useState(employee.teilzeit_bis ?? "");
const [contractType, setContractType] = useState<ContractType>(employee.contract_type);
const [contractEndDate, setContractEndDate] = useState(employee.contract_end_date ?? "");
const [paygrade, setPaygrade] = useState<PaygradeType>(employee.paygrade);
const [role, setRole] = useState<RoleEmploymentValue>({
workerType: employee.worker_type ?? "Angestellte:r",
mitarbeiterart: employee.mitarbeiterart ?? MITARBEITERART_STANDARD,
// Hier gesetzt und im Assistenten nicht: dort steht die Besetzungsart im
// Schritt „Position". Ihr Wechsel von extern auf intern ist eine
// Übernahme und wird als eigenes Ereignis protokolliert.
source: employee.source ?? "Extern",
collectiveAgreement: employee.collective_agreement ?? "Handel",
workDays: employee.work_days ?? ["Mo", "Di", "Mi", "Do", "Fr"],
isBetriebsrat: employee.is_betriebsrat ?? false,
hasDienstwagen: employee.has_dienstwagen ?? false,
hasKuendigungsschutz: employee.has_kuendigungsschutz ?? false,
kuendigungsschutzBis: employee.kuendigungsschutz_bis ?? "",
kuendigungsschutzGrund: employee.kuendigungsschutz_grund ?? "",
kuendigungsschutzAb: employee.kuendigungsschutz_ab ?? "",
istBeguenstigtBehindert: employee.ist_beguenstigt_behindert ?? false,
// Als Text und nicht als Zahl: ein leeres Zahlenfeld wäre 0, und 0
// bedeutet hier „kein Bescheid", nicht „Grad null".
behinderungGrad: employee.behinderung_grad === null ? "" : String(employee.behinderung_grad),
behinderungAb: employee.behinderung_ab ?? "",
behinderungBis: employee.behinderung_bis ?? "",
dienstwagenArt: employee.dienstwagen_art ?? "Verbrenner",
isLateraleFuehrung: employee.is_laterale_fuehrung ?? false,
isCLevel: employee.is_c_level ?? false,
});
function updateRole(patch: Partial<RoleEmploymentValue>) {
setRole((prev) => ({ ...prev, ...patch }));
}
// Dieselbe Regel wie in RoleEmploymentFields: der Personenkreis zieht das
// Kennzeichen mit. Hier noch einmal, weil nicht das Formular speichert,
// sondern diese Seite — und was gezeigt wird, muss auch abgeschickt werden.
const istBehindert = role.istBeguenstigtBehindert || role.kuendigungsschutzGrund === GRUND_BEGUENSTIGT_BEHINDERT;
function handleEmploymentTypeChange(value: EmploymentType) {
setEmploymentType(value);
@@ -112,25 +150,66 @@ export function DatenAendernPanel({
birth_date: birthDate,
sv_nummer: svNummer,
nationality,
// Wechselt die Staatsbürgerschaft in den Freizügigkeitsraum, fällt
// der Titel weg — sonst bliebe er als Rest an einer Person hängen,
// die ihn nicht mehr braucht. Die Datenbank prüft diese Kopplung
// bewusst nicht (siehe Migration), also gehört sie hierher.
hat_aufenthaltstitel: titelNoetig ? hatTitel : false,
aufenthaltstitel_bis: titelNoetig && hatTitel ? titelBis : "",
address,
postal_code: postalCode,
city,
address_country: addressCountry,
email,
phone,
// Getrimmt und als leere Zeichenkette durchgereicht: die Datenbank
// macht daraus null (nullif), damit sich eine Angabe auch wieder
// entfernen lässt. Ungetrimmt käme ein Feld, in dem nur ein
// Leerzeichen stehen geblieben ist, als Inhalt in der Spalte an.
email: email.trim(),
company_email: companyEmail.trim(),
cornerstone_id: cornerstoneId.trim(),
phone: phone.trim(),
// Der Notfallkontakt läuft über seinen eigenen Abschnitt weiter unten
// — wie die Angehörigen. Stünde er zusätzlich hier, schrieben zwei
// Stellen dasselbe Feld, und welche gewinnt, hinge an der
// Reihenfolge.
},
contract: {
employment_type: employmentType,
weekly_hours: Number(weeklyHours),
contract_type: contractType,
contract_end_date: contractType === "befristet" ? contractEndDate : "",
paygrade,
},
role: {
worker_type: role.workerType,
mitarbeiterart: role.mitarbeiterart,
source: role.source,
collective_agreement: role.collectiveAgreement,
work_days: role.workDays,
is_betriebsrat: role.isBetriebsrat,
has_dienstwagen: role.hasDienstwagen,
dienstwagen_art: role.hasDienstwagen ? role.dienstwagenArt : "",
has_kuendigungsschutz: role.hasKuendigungsschutz,
// Leer statt des Wertes, wenn das Kennzeichen weg ist: die Bedingung
// in der Datenbank duldet keinen Rest ohne Bezug, und die Funktion
// räumt ihn auf demselben Weg weg wie beim Dienstwagen.
kuendigungsschutz_bis: role.hasKuendigungsschutz ? role.kuendigungsschutzBis : "",
kuendigungsschutz_grund: role.hasKuendigungsschutz ? role.kuendigungsschutzGrund : "",
kuendigungsschutz_ab: role.hasKuendigungsschutz ? role.kuendigungsschutzAb : "",
ist_beguenstigt_behindert: istBehindert,
behinderung_grad: istBehindert ? role.behinderungGrad : "",
behinderung_ab: istBehindert ? role.behinderungAb : "",
behinderung_bis: istBehindert ? role.behinderungBis : "",
// Die Teilzeitvariante wird nur mitgeschickt, wenn sich die Stunden
// tatsächlich ändern. Sonst schriebe jede Adressänderung den Wert
// erneut — und setzte ihn bei „Vertragliche Stundenänderung" sogar
// zurück, obwohl niemand die Stunden angefasst hat.
...(stundenGeaendert
? {
teilzeit_art: stundenGrund === "Vertragliche Stundenänderung" ? "" : stundenGrund,
teilzeit_bis: stundenGrund === "Vertragliche Stundenänderung" ? "" : teilzeitBis,
}
: {}),
is_laterale_fuehrung: role.isLateraleFuehrung,
is_c_level: role.isCLevel,
},
@@ -197,6 +276,34 @@ export function DatenAendernPanel({
<CountryPicker {...p} value={nationality} onChange={setNationality} countries={UN_COUNTRIES} placeholder="Staatsbürgerschaft suchen…" />
)}
</Field>
{/* Nur wo er verlangt ist. Bei Freizügigkeit — EU, EWR, Schweiz —
wäre die Frage gegenstandslos, und ein „Nein" im Formular
sähe aus wie eine Auskunft. */}
{titelNoetig && (
<>
<SelectField
label="Aufenthaltstitel"
dense
value={hatTitel ? "ja" : "nein"}
onChange={(v) => setHatTitel(v === "ja")}
options={[
{ value: "nein", label: "Nein" },
{ value: "ja", label: "Ja" },
]}
hint="Bei Staatsbürgerschaften ausserhalb von EU, EWR und Schweiz."
/>
{hatTitel && (
<TextField
label="Aufenthaltstitel gültig bis"
dense
type="date"
value={titelBis}
onChange={setTitelBis}
hint="Optional. Leer lassen, wenn unbefristet."
/>
)}
</>
)}
<TextField label="Adresse (Straße und Hausnummer)" dense value={address} onChange={setAddress} />
<div className="grid grid-cols-[minmax(0,1fr)_minmax(0,2fr)] gap-3">
<TextField label="Postleitzahl" dense inputMode="numeric" value={postalCode} onChange={setPostalCode} />
@@ -205,9 +312,12 @@ export function DatenAendernPanel({
<Field label="Land" dense>
{(p) => <CountryPicker {...p} value={addressCountry} onChange={setAddressCountry} countries={UN_COUNTRIES} placeholder="Land suchen…" />}
</Field>
<TextField label="E-Mail" dense type="email" value={email} onChange={setEmail} />
<TextField label="E-Mail (privat)" dense type="email" value={email} onChange={setEmail} />
<TextField label="Firmen-E-Mail" dense type="email" value={companyEmail} onChange={setCompanyEmail} />
<TextField label="Cornerstone-ID" dense value={cornerstoneId} onChange={setCornerstoneId} />
<TextField label="Telefon" dense type="tel" value={phone} onChange={setPhone} />
</div>
</div>
<div>
@@ -232,6 +342,26 @@ export function DatenAendernPanel({
disabled={employmentType === "Vollzeit"}
onChange={setWeeklyHours}
/>
{stundenGeaendert && (
<SelectField
label="Grund der Stundenänderung"
dense
value={stundenGrund}
onChange={setStundenGrund}
options={STUNDEN_GRUENDE.map((g) => ({ value: g, label: g }))}
hint="Steht danach am Profil und lässt sich auswerten."
/>
)}
{stundenGeaendert && stundenGrund !== "Vertragliche Stundenänderung" && (
<TextField
label="Teilzeit bis"
dense
type="date"
value={teilzeitBis}
onChange={setTeilzeitBis}
hint="Optional. Leer lassen, solange das Ende nicht feststeht."
/>
)}
<SelectField
label="Vertragsart"
dense
@@ -245,6 +375,18 @@ export function DatenAendernPanel({
{contractType === "befristet" && (
<TextField label="Befristet bis" required dense type="date" value={contractEndDate} onChange={setContractEndDate} />
)}
{/* Auch über die Beförderung zu setzen — und trotzdem hier. Eine
Umstufung ist nicht immer eine Beförderung: „da stand von
Anfang an die falsche Stufe" ist eine Richtigstellung, und die
soll keine Planstelle wechseln und kein Ereignis „Beförderung"
in der Historie hinterlassen. */}
<SelectField
label="Hay-Grade"
dense
value={paygrade}
onChange={(v) => setPaygrade(v as PaygradeType)}
options={HAY_GRADES}
/>
</div>
</div>
@@ -254,6 +396,22 @@ export function DatenAendernPanel({
</div>
<AngehoerigeSection employeeId={employee.id} dependents={dependents} effectiveDate={effectiveDate} />
{/* Derselbe Abschnitt wie im Reiter „Stammdaten", unmittelbar unter den
Angehörigen — beides Personen im Umfeld, beides dieselbe Tabelle
mit denselben Knöpfen. Hier standen drei Eingabefelder: fachlich
dasselbe, aber daneben eine zweite Bauform für denselben Zweck.
Beide Abschnitte laufen jetzt über das „Wirksam ab" dieses
Formulars. */}
<NotfallkontaktSection
employeeId={employee.id}
effectiveDate={effectiveDate}
kontakt={{
name: employee.emergency_contact_name,
telefon: employee.emergency_contact_phone,
verhaeltnis: employee.emergency_contact_relation,
}}
/>
</div>
</SlideOver>
);

View File

@@ -8,18 +8,29 @@ import { SelectField, TextField, TextareaField } from "@/components/ui/Field";
import { SegmentedControl } from "@/components/ui/SegmentedControl";
import { SlideOver } from "@/components/ui/SlideOver";
import { useToast } from "@/components/ui/Toast";
import { ABSENCE_TYPES, absenceLabel } from "@/lib/absence";
import { fmtDate } from "@/lib/format";
import type { Database } from "@/lib/supabase/types";
import { ABSENCE_TYPES, absenceLabel, RUECKKEHR_GRUENDE } from "@/lib/absence";
import { fmtDate, fmtName } from "@/lib/format";
import type { Database, EmploymentStatus } from "@/lib/types";
type EmployeeRow = Database["public"]["Tables"]["employees"]["Row"];
type Mode = "adjust" | "return";
type EmploymentMode = "unverändert" | "Vollzeit" | "Teilzeit";
export function KarenzPanel({ open, onClose, employee }: { open: boolean; onClose: () => void; employee: EmployeeRow }) {
export function KarenzPanel({
open,
onClose,
employee,
status,
}: {
open: boolean;
onClose: () => void;
employee: EmployeeRow;
/** Der zum heutigen Tag abgeleitete Status — nicht `employee.status`, die Spalte hängt nach. */
status: EmploymentStatus;
}) {
const { showToast } = useToast();
const router = useRouter();
const isOnKarenz = employee.status === "Karenz";
const isOnKarenz = status === "Karenz";
const [mode, setMode] = useState<Mode>("adjust");
const [pending, setPending] = useState(false);
@@ -33,7 +44,18 @@ export function KarenzPanel({ open, onClose, employee }: { open: boolean; onClos
const [returnDate, setReturnDate] = useState("");
const [employmentMode, setEmploymentMode] = useState<EmploymentMode>("unverändert");
const [weeklyHours, setWeeklyHours] = useState("20");
// Warum weniger Stunden: Wiedereingliederungs- oder Elternteilzeit. Beide
// beginnen typischerweise genau dann, wenn die Abwesenheit endet — deshalb
// steht die Frage hier und nicht in einem zweiten Vorgang danach.
const [reduktionsgrund, setReduktionsgrund] = useState<string>("");
const [teilzeitBis, setTeilzeitBis] = useState("");
// Die Stunden, die vor der Abwesenheit galten — mit Komma, wie man sie
// hierzulande schreibt.
const stundenText = String(employee.weekly_hours).replace(".", ",");
// Absichtlich leer statt vorbelegt: eine Zahl, die schon dasteht, wird
// bestätigt statt erfasst. Die reduzierten Stunden stehen in einer
// Vereinbarung, und die muss jemand ablesen.
const [weeklyHours, setWeeklyHours] = useState("");
const diffDays =
isOnKarenz && employee.karenz_return_date && newReturnDate
@@ -89,9 +111,15 @@ export function KarenzPanel({ open, onClose, employee }: { open: boolean; onClos
showToast("Bitte Rückkehrdatum angeben.", "error");
return;
}
if (employmentMode === "Teilzeit" && (Number(weeklyHours) <= 0 || Number(weeklyHours) >= 38.5)) {
showToast("Wochenstunden müssen zwischen 0 und 38,5 liegen.", "error");
return;
if (employmentMode === "Teilzeit") {
if (!weeklyHours.trim()) {
showToast("Bitte die reduzierten Wochenstunden erfassen.", "error");
return;
}
if (Number(weeklyHours) <= 0 || Number(weeklyHours) >= 38.5) {
showToast("Wochenstunden müssen zwischen 0 und 38,5 liegen.", "error");
return;
}
}
setPending(true);
const result = await recordKarenzReturn({
@@ -99,6 +127,8 @@ export function KarenzPanel({ open, onClose, employee }: { open: boolean; onClos
return_date: returnDate,
employment_mode: employmentMode,
weekly_hours: employmentMode === "Teilzeit" ? Number(weeklyHours) : undefined,
reduction_reason: employmentMode === "Teilzeit" ? reduktionsgrund || undefined : undefined,
teilzeit_bis: employmentMode === "Teilzeit" && reduktionsgrund ? teilzeitBis || undefined : undefined,
});
setPending(false);
if (result.success) {
@@ -115,7 +145,7 @@ export function KarenzPanel({ open, onClose, employee }: { open: boolean; onClos
open={open}
onClose={onClose}
title={isOnKarenz ? "Langzeitabwesenheit verwalten" : "Langzeitabwesenheit erfassen"}
subtitle={`${employee.first_name} ${employee.last_name} · ${employee.job_title}`}
subtitle={`${fmtName(employee.first_name, employee.last_name)} · ${employee.job_title}`}
footer={
<>
<Button variant="ghost" onClick={onClose}>
@@ -169,7 +199,7 @@ export function KarenzPanel({ open, onClose, employee }: { open: boolean; onClos
{mode === "adjust" && (
<>
<p className="rounded bg-surface px-3 py-2 text-sm text-ink-body">
<span className="font-semibold">{absenceLabel(employee.status, employee.absence_type)}</span>
<span className="font-semibold">{absenceLabel(status, employee.absence_type)}</span>
{" · Rückkehr "}
{fmtDate(employee.karenz_return_date)}
</p>
@@ -191,22 +221,46 @@ export function KarenzPanel({ open, onClose, employee }: { open: boolean; onClos
value={employmentMode}
onChange={(v) => setEmploymentMode(v as EmploymentMode)}
options={[
{ value: "unverändert", label: "unverändert" },
{ value: "Vollzeit", label: "Vollzeit (38,5h)" },
{ value: "Teilzeit", label: "Teilzeit-Elternteilzeit" },
// Die Stunden, die zuletzt gearbeitet wurden, stehen in der
// Beschriftung. „unverändert" allein zwang dazu, in der
// Akte nachzusehen, worauf man sich da einlässt.
{ value: "unverändert", label: `Wie vor Abwesenheit (${stundenText} h)` },
{ value: "Teilzeit", label: "Reduziert" },
]}
/>
{employmentMode === "Teilzeit" && (
<TextField
label="Wochenstunden"
required
type="number"
step="0.5"
max="38"
value={weeklyHours}
onChange={setWeeklyHours}
hint="Muss unter 38,5 liegen."
/>
<>
<TextField
label="Reduzierte Wochenstunden"
required
type="number"
step="0.5"
max="38"
value={weeklyHours}
onChange={setWeeklyHours}
placeholder={`weniger als ${stundenText}`}
hint="Muss unter 38,5 liegen."
/>
<SelectField
label="Grund der Reduktion"
value={reduktionsgrund}
onChange={setReduktionsgrund}
options={[
{ value: "", label: "Ohne besonderen Grund" },
...RUECKKEHR_GRUENDE.map((g) => ({ value: g, label: g })),
]}
hint="Steht danach am Profil und lässt sich auswerten."
/>
{reduktionsgrund && (
<TextField
label="Teilzeit bis"
type="date"
value={teilzeitBis}
onChange={setTeilzeitBis}
hint="Optional. Leer lassen, solange das Ende nicht feststeht."
/>
)}
</>
)}
</>
)}

View File

@@ -1,44 +1,86 @@
"use client";
import { useRouter } from "next/navigation";
import { useState } from "react";
import { useMemo, useState } from "react";
import { promoteEmployee } from "@/actions/employees";
import { Button } from "@/components/ui/Button";
import { SelectField, TextField } from "@/components/ui/Field";
import { SlideOver } from "@/components/ui/SlideOver";
import { useToast } from "@/components/ui/Toast";
import type { Database, PaygradeType } from "@/lib/supabase/types";
import { HAY_GRADES } from "@/lib/hay-grade";
import type { OpenPositionResolved } from "@/lib/positions";
import type { Database, PaygradeType } from "@/lib/types";
import { fmtName } from "@/lib/format";
type EmployeeRow = Database["public"]["Tables"]["employees"]["Row"];
const PAYGRADES: { value: PaygradeType; label: string }[] = [
{ value: "A", label: "A – Einstieg" },
{ value: "B", label: "B – Qualifiziert" },
{ value: "C", label: "C – Erfahren" },
{ value: "D", label: "D – Spezialist:in" },
{ value: "E", label: "E – Teamleitung" },
{ value: "F", label: "F – Bereichsleitung / GF" },
];
// Eine Beförderung kann auf derselben Planstelle stattfinden oder auf eine
// andere führen. Beides kommt vor: jemand wächst auf seiner Stelle, oder er
// rückt auf eine höhere — und dann ist die Zielstelle dieselbe Auswahl wie
// bei der Versetzung.
type Stellenwahl = "selbe" | "neue";
export function PromotePanel({ open, onClose, employee }: { open: boolean; onClose: () => void; employee: EmployeeRow }) {
export function PromotePanel({
open,
onClose,
employee,
openPositions,
}: {
open: boolean;
onClose: () => void;
employee: EmployeeRow;
openPositions: OpenPositionResolved[];
}) {
const { showToast } = useToast();
const router = useRouter();
const [effectiveDate, setEffectiveDate] = useState("");
const [newTitle, setNewTitle] = useState(employee.job_title);
const [paygrade, setPaygrade] = useState<PaygradeType>(employee.paygrade);
const [stellenwahl, setStellenwahl] = useState<Stellenwahl>("selbe");
const [positionId, setPositionId] = useState("");
const [pending, setPending] = useState(false);
const options = useMemo(
() =>
openPositions
.slice()
.sort((a, b) => a.orgLabel.localeCompare(b.orgLabel, "de") || a.title.localeCompare(b.title, "de"))
.map((p) => ({ value: p.id, label: `${p.orgLabel} · ${p.title} (${p.position_number})` })),
[openPositions]
);
const selected = openPositions.find((p) => p.id === positionId);
/**
* Die Stelle wählen schlägt ihre Tätigkeit als neue Bezeichnung vor.
*
* Nur ein Vorschlag: `employees.job_title` darf von der Planstelle
* abweichen, und wer eine eigene Bezeichnung tippt, soll sie behalten.
* Deshalb wird nur überschrieben, solange das Feld unverändert auf dem
* alten Titel steht.
*/
function stelleWaehlen(id: string) {
setPositionId(id);
const stelle = openPositions.find((p) => p.id === id);
if (stelle && newTitle === employee.job_title) setNewTitle(stelle.title);
}
async function handleSubmit() {
if (!effectiveDate || !newTitle) {
showToast("Bitte alle Pflichtfelder ausfüllen.", "error");
return;
}
if (stellenwahl === "neue" && !positionId) {
showToast("Bitte die neue Planstelle auswählen.", "error");
return;
}
setPending(true);
const result = await promoteEmployee({
employee_id: employee.id,
effective_date: effectiveDate,
new_title: newTitle,
new_paygrade: paygrade,
target_position_id: stellenwahl === "neue" ? positionId : undefined,
});
setPending(false);
if (result.success) {
@@ -55,7 +97,7 @@ export function PromotePanel({ open, onClose, employee }: { open: boolean; onClo
open={open}
onClose={onClose}
title="Beförderung"
subtitle={`${employee.first_name} ${employee.last_name} · ${employee.job_title}`}
subtitle={`${fmtName(employee.first_name, employee.last_name)} · ${employee.job_title}`}
footer={
<>
<Button variant="ghost" onClick={onClose}>
@@ -71,12 +113,62 @@ export function PromotePanel({ open, onClose, employee }: { open: boolean; onClo
>
<div className="flex flex-col gap-4">
<TextField label="Wirksam ab" required type="date" value={effectiveDate} onChange={setEffectiveDate} />
<fieldset>
<legend className="mb-1.5 text-sm font-semibold text-ink-body">Planstelle</legend>
<div className="flex flex-col gap-1.5">
<label className="flex items-center gap-2 text-sm text-ink-body">
<input
type="radio"
name="stellenwahl"
checked={stellenwahl === "selbe"}
onChange={() => setStellenwahl("selbe")}
/>
Selbe Planstelle
</label>
<label className="flex items-center gap-2 text-sm text-ink-body">
<input
type="radio"
name="stellenwahl"
checked={stellenwahl === "neue"}
onChange={() => setStellenwahl("neue")}
disabled={options.length === 0}
/>
Neue Planstelle
{options.length === 0 && <span className="text-xs text-ink-muted">(derzeit keine freie)</span>}
</label>
</div>
</fieldset>
{stellenwahl === "neue" && (
<>
<SelectField
label="Neue Planstelle"
required
value={positionId}
onChange={stelleWaehlen}
placeholder="Bitte wählen…"
options={options}
/>
{selected && (
<div className="rounded border border-border bg-surface p-3 text-sm text-ink-body">
<div className="font-semibold text-ink">{selected.title}</div>
<div className="text-xs text-ink-muted">{selected.orgLabel}</div>
<div className="mt-1 text-xs text-ink-muted">
{selected.is_chief ? "Leitungsplanstelle" : "Mitarbeiterplanstelle"}
{selected.managerName ? ` · berichtet an ${selected.managerName}` : ""}
</div>
</div>
)}
</>
)}
<TextField label="Neue Position" required value={newTitle} onChange={setNewTitle} />
<SelectField
label="Paygrade"
label="Hay-Grade"
value={paygrade}
onChange={(v) => setPaygrade(v as PaygradeType)}
options={PAYGRADES}
options={HAY_GRADES}
/>
</div>
</SlideOver>

View File

@@ -1,65 +0,0 @@
"use client";
import { useRouter } from "next/navigation";
import { useState } from "react";
import { rehireEmployee } from "@/actions/employees";
import { Button } from "@/components/ui/Button";
import { TextField } from "@/components/ui/Field";
import { SlideOver } from "@/components/ui/SlideOver";
import { useToast } from "@/components/ui/Toast";
import { fmtDate } from "@/lib/format";
import type { Database } from "@/lib/supabase/types";
type EmployeeRow = Database["public"]["Tables"]["employees"]["Row"];
export function RehirePanel({ open, onClose, employee }: { open: boolean; onClose: () => void; employee: EmployeeRow }) {
const { showToast } = useToast();
const router = useRouter();
const [rehireDate, setRehireDate] = useState("");
const [pending, setPending] = useState(false);
async function handleSubmit() {
if (!rehireDate) {
showToast("Bitte ein Wiedereintrittsdatum angeben.", "error");
return;
}
setPending(true);
const result = await rehireEmployee({ employee_id: employee.id, rehire_date: rehireDate });
setPending(false);
if (result.success) {
showToast(`${employee.first_name} ${employee.last_name} wurde wiedereingestellt.`);
router.refresh();
onClose();
} else {
showToast(result.error ?? "Fehler beim Speichern.", "error");
}
}
return (
<SlideOver
open={open}
onClose={onClose}
title="Wiedereinstellung"
subtitle={`${employee.first_name} ${employee.last_name}`}
footer={
<>
<Button variant="ghost" onClick={onClose}>
Abbrechen
</Button>
<Button onClick={handleSubmit} pending={pending}>
Wiedereinstellen
</Button>
</>
}
>
<div className="flex flex-col gap-4">
<div className="rounded border border-border bg-surface p-3 text-sm">
<p className="text-xs font-semibold uppercase tracking-wide text-ink-muted">Letzte Position</p>
<p className="mt-1 text-ink">{employee.job_title}</p>
<p className="text-xs text-ink-muted">Ausgetreten am {fmtDate(employee.exit_date)}</p>
</div>
<TextField label="Wiedereintritt am" required type="date" value={rehireDate} onChange={setRehireDate} />
</div>
</SlideOver>
);
}

View File

@@ -7,39 +7,68 @@ import { Button } from "@/components/ui/Button";
import { SelectField, TextField, TextareaField } from "@/components/ui/Field";
import { SlideOver } from "@/components/ui/SlideOver";
import { useToast } from "@/components/ui/Toast";
import type { Database } from "@/lib/supabase/types";
import { AUSTRITTSART_LABELS, AUSTRITTSARTEN, BEENDIGUNG_NO_SHOW, BEENDIGUNGSART_WERTE } from "@/lib/beendigung";
import type { Austrittsart, Database, EmploymentStatus } from "@/lib/types";
import { fmtDate, fmtName } from "@/lib/format";
type EmployeeRow = Database["public"]["Tables"]["employees"]["Row"];
const EXIT_REASONS = ["Einvernehmliche Auflösung", "Kündigung AN", "Kündigung AG", "Befristungsablauf", "Pensionierung", "Entlassung"];
const CHECKLIST_ITEMS = ["IT-Zugänge deaktivieren", "Hardware retournieren", "ÖGK-Abmeldung", "Endabrechnung & Dienstzeugnis"];
// Die Liste steht in lib/beendigung.ts, nicht mehr hier: der Berichtemanager
// braucht sie ebenso, und zwei Listen liefen auseinander.
const NO_SHOW = BEENDIGUNG_NO_SHOW;
type TerminatePanelProps = {
open: boolean;
onClose: () => void;
employee: EmployeeRow;
/** Der zum heutigen Tag abgeleitete Status — nicht `employee.status`, die Spalte hängt nach. */
status: EmploymentStatus;
directReportCount: number;
};
export function TerminatePanel({ open, onClose, employee, directReportCount }: TerminatePanelProps) {
export function TerminatePanel({ open, onClose, employee, status, directReportCount }: TerminatePanelProps) {
const { showToast } = useToast();
const router = useRouter();
const [exitDate, setExitDate] = useState("");
const [reason, setReason] = useState(EXIT_REASONS[0]);
// Wer noch gar nicht angefangen hat, tritt fast nie aus einem anderen Grund
// aus. Die Vorbelegung nimmt den wahrscheinlichen Fall vorweg, ohne die
// übrigen zu verstellen.
const [reason, setReason] = useState(status === "Geplant" ? NO_SHOW : BEENDIGUNGSART_WERTE[0]);
// Leer als Vorbelegung: die Angabe ist freiwillig, und eine vorausgewählte
// Seite wäre eine Behauptung, die niemand getroffen hat.
const [austrittsart, setAustrittsart] = useState<Austrittsart | "">("");
const [note, setNote] = useState("");
const [checked, setChecked] = useState<boolean[]>(CHECKLIST_ITEMS.map(() => false));
const [pending, setPending] = useState(false);
// Bei einem Nichtantritt ist das Datum nicht frei wählbar: es ist der Tag,
// an dem die Person hätte anfangen sollen. Die Datenbank setzt es ohnehin
// so; hier steht es sichtbar, damit niemand ein Datum eintippt, das dann
// stillschweigend übergangen wird.
const istNoShow = reason === NO_SHOW;
const wirksamesDatum = istNoShow ? employee.entry_date : exitDate;
async function handleSubmit() {
if (!exitDate) {
if (!wirksamesDatum) {
showToast("Bitte ein Austrittsdatum angeben.", "error");
return;
}
setPending(true);
const result = await terminateEmployee({ employee_id: employee.id, exit_date: exitDate, exit_reason: reason, note });
const result = await terminateEmployee({
employee_id: employee.id,
exit_date: wirksamesDatum,
exit_reason: reason,
// Leer statt undefined: die SQL-Funktion macht daraus null, und null
// heisst „nicht erfasst" — das ist der ehrliche Wert.
austrittsart,
note,
});
setPending(false);
if (result.success) {
showToast(`Austritt für ${employee.first_name} ${employee.last_name} erfasst.`);
showToast(
istNoShow
? `${employee.first_name} ${employee.last_name} ist nicht angetreten.`
: `Austritt für ${employee.first_name} ${employee.last_name} erfasst.`
);
router.refresh();
onClose();
} else {
@@ -51,8 +80,8 @@ export function TerminatePanel({ open, onClose, employee, directReportCount }: T
<SlideOver
open={open}
onClose={onClose}
title="Austritt"
subtitle={`${employee.first_name} ${employee.last_name} · ${employee.job_title}`}
title={istNoShow ? "Nicht angetreten" : "Austritt"}
subtitle={`${fmtName(employee.first_name, employee.last_name)} · ${employee.job_title}`}
footer={
<>
<Button variant="ghost" onClick={onClose}>
@@ -65,34 +94,89 @@ export function TerminatePanel({ open, onClose, employee, directReportCount }: T
}
>
<div className="flex flex-col gap-4">
{/* Zuerst, und nicht zu übersehen: bei besonderem Kündigungsschutz
gelten eigene Regeln, bevor beendet werden darf. Die Anwendung
entscheidet das nicht — sie darf es aber auch nicht verschweigen,
und im Vertragsblatt nachzusehen ist genau der Schritt, den man
unter Zeitdruck auslässt. */}
{employee.has_kuendigungsschutz && (
<div className="rounded border border-danger-solid bg-danger-bg px-3 py-2 text-sm font-semibold text-danger-text">
Achtung: besonderer Kündigungsschutz
{employee.kuendigungsschutz_bis ? ` bis ${fmtDate(employee.kuendigungsschutz_bis)}` : " (Ende nicht erfasst)"}.
<span className="block font-normal">
Vor einer Beendigung ist zu prüfen, ob sie zulässig ist — je nach Grund braucht es eine Zustimmung des
Betriebsrats oder des Gerichts.
</span>
</div>
)}
{directReportCount > 0 && (
<div className="rounded bg-warning-bg px-3 py-2 text-sm text-warning-text">
{directReportCount} direkte Berichte werden automatisch der nächsthöheren Führungskraft zugeordnet.
</div>
)}
<TextField label="Austrittsdatum" required type="date" value={exitDate} onChange={setExitDate} />
{/* ── Zwei Angaben, die einander nicht bestimmen ──────────────
Erst die Beendigungsart, darunter der Anstoss. Beide Listen sind
vollständig und keine schränkt die andere ein.
Der erste Entwurf hatte es umgekehrt: oben die Austrittsart, und
sie filterte die Beendigungsarten darunter, weil der Anstoss aus
der Art ableitbar schien. In Österreich ist er das nicht — die
einvernehmliche Auflösung ist der Regelfall und kann von beiden
Seiten ausgehen. Die Begründung steht in lib/beendigung.ts.
Unter der Beendigungsart stand ausserdem der abgeleitete Anstoss
als Hinweis. Er erschien von selbst und sah aus wie ein Fehler des
Formulars; er ist weg. */}
<SelectField
label="Beendigungsart"
value={reason}
onChange={setReason}
options={EXIT_REASONS.map((r) => ({ value: r, label: r }))}
options={BEENDIGUNGSART_WERTE.map((r) => ({ value: r, label: r === NO_SHOW ? "No Show (nicht angetreten)" : r }))}
/>
<SelectField
label="Freiwillig oder unfreiwillig"
value={austrittsart}
onChange={(v) => setAustrittsart((v || "") as Austrittsart | "")}
options={[
// „Nicht erfasst" als Vorbelegung und nicht eine der beiden
// Seiten: ein Befristungsablauf geschieht auf niemandes
// Betreiben, und ein Nichtantritt ist gar kein Austritt. Eine
// erzwungene Antwort wäre dort eine erfundene Zahl.
{ value: "", label: "Nicht erfasst" },
...AUSTRITTSARTEN.map((a) => ({ value: a, label: AUSTRITTSART_LABELS[a] })),
]}
hint="Für die Fluktuationsauswertung. Lässt sich aus der Beendigungsart nicht ableiten."
/>
<TextField
label={istNoShow ? "Wirksam am (Eintrittstag)" : "Austrittsdatum"}
required
type="date"
value={wirksamesDatum}
disabled={istNoShow}
onChange={setExitDate}
hint={
istNoShow
? "Wer nie angetreten ist, scheidet am Tag seines Eintritts aus. Damit gibt es keinen Tag, an dem die Person als beschäftigt zählt."
: undefined
}
/>
<TextareaField label="Anmerkung" rows={3} value={note} onChange={setNote} />
<fieldset>
<legend className="mb-2 text-sm font-semibold text-ink">Offboarding-Checkliste</legend>
<div className="flex flex-col gap-2">
{CHECKLIST_ITEMS.map((item, i) => (
<label key={item} className="flex items-center gap-2 text-sm text-ink-body">
<input
type="checkbox"
checked={checked[i]}
onChange={(e) => setChecked((prev) => prev.map((c, idx) => (idx === i ? e.target.checked : c)))}
/>
{item}
</label>
))}
</div>
</fieldset>
{istNoShow && (
<p className="rounded bg-surface px-3 py-2 text-sm text-ink-body">
Die Planstelle wird wieder frei und gilt als nie besetzt. In allen Auswertungen zählt die Person an keinem
Stichtag als beschäftigt.
</p>
)}
{/* Bei einem Nichtantritt wurde nichts ausgegeben, was zurückkäme —
deshalb entsteht dort auch keine Offboarding-Checkliste. Für einen
echten Austritt legt terminateEmployee sie in derselben
Transaktion an; hier steht nur die Ankündigung, damit niemand sie
hier sucht und nichts findet. */}
{!istNoShow && (
<p className="rounded bg-surface px-3 py-2 text-sm text-ink-body">
Nach der Bestätigung steht im Reiter „Offboarding“ eine Checkliste zur Verfügung.
</p>
)}
</div>
</SlideOver>
);

View File

@@ -7,48 +7,52 @@ import { Button } from "@/components/ui/Button";
import { SelectField, TextField } from "@/components/ui/Field";
import { SlideOver } from "@/components/ui/SlideOver";
import { useToast } from "@/components/ui/Toast";
import type { Database } from "@/lib/supabase/types";
import type { OpenPositionResolved } from "@/lib/positions";
import type { Database } from "@/lib/types";
import { fmtName } from "@/lib/format";
type EmployeeRow = Database["public"]["Tables"]["employees"]["Row"];
type Division = Database["public"]["Tables"]["divisions"]["Row"];
type Department = Database["public"]["Tables"]["departments"]["Row"];
type Team = Database["public"]["Tables"]["teams"]["Row"];
type TransferPanelProps = {
open: boolean;
onClose: () => void;
employee: EmployeeRow;
divisions: Division[];
departments: Department[];
teams: Team[];
currentTeamId: string | null;
openPositions: OpenPositionResolved[];
};
export function TransferPanel({ open, onClose, employee, divisions, departments, teams, currentTeamId }: TransferPanelProps) {
// Eine Versetzung ist der Wechsel auf eine andere Planstelle — nicht mehr die
// Angabe eines Zielteams samt frei getipptem Titel. Bereich, Abteilung und
// Team ergeben sich aus der Einheit der Zielplanstelle, die neue Tätigkeit aus
// ihrem Job. Damit kann eine Versetzung gar nicht erst irgendwo landen, wo es
// keine Stelle gibt.
export function TransferPanel({ open, onClose, employee, openPositions }: TransferPanelProps) {
const { showToast } = useToast();
const router = useRouter();
const [effectiveDate, setEffectiveDate] = useState("");
const [divisionId, setDivisionId] = useState(employee.division_id);
const [teamId, setTeamId] = useState(currentTeamId ?? "");
const [newTitle, setNewTitle] = useState("");
const [positionId, setPositionId] = useState("");
const [pending, setPending] = useState(false);
const teamsInDivision = useMemo(() => {
const deptIds = new Set(departments.filter((d) => d.division_id === divisionId).map((d) => d.id));
return teams.filter((t) => deptIds.has(t.department_id));
}, [departments, teams, divisionId]);
const options = useMemo(
() =>
openPositions
.slice()
.sort((a, b) => a.orgLabel.localeCompare(b.orgLabel, "de") || a.title.localeCompare(b.title, "de"))
.map((p) => ({ value: p.id, label: `${p.orgLabel} · ${p.title} (${p.position_number})` })),
[openPositions]
);
const selected = openPositions.find((p) => p.id === positionId);
async function handleSubmit() {
if (!effectiveDate || !teamId) {
showToast("Bitte Datum und Zielteam angeben.", "error");
if (!effectiveDate || !positionId) {
showToast("Bitte Datum und Zielplanstelle angeben.", "error");
return;
}
setPending(true);
const result = await transferEmployee({
employee_id: employee.id,
effective_date: effectiveDate,
new_team_id: teamId,
new_title: newTitle || undefined,
target_position_id: positionId,
});
setPending(false);
if (result.success) {
@@ -65,13 +69,13 @@ export function TransferPanel({ open, onClose, employee, divisions, departments,
open={open}
onClose={onClose}
title="Versetzung"
subtitle={`${employee.first_name} ${employee.last_name} · ${employee.job_title}`}
subtitle={`${fmtName(employee.first_name, employee.last_name)} · ${employee.job_title}`}
footer={
<>
<Button variant="ghost" onClick={onClose}>
Abbrechen
</Button>
<Button onClick={handleSubmit} pending={pending}>
<Button onClick={handleSubmit} pending={pending} disabled={options.length === 0}>
Versetzen
</Button>
</>
@@ -79,31 +83,33 @@ export function TransferPanel({ open, onClose, employee, divisions, departments,
>
<div className="flex flex-col gap-4">
<TextField label="Wirksam ab" required type="date" value={effectiveDate} onChange={setEffectiveDate} />
<SelectField
label="Neuer Bereich"
required
value={divisionId}
onChange={(v) => {
setDivisionId(v);
setTeamId("");
}}
options={divisions.map((d) => ({ value: d.id, label: d.name }))}
/>
<SelectField
label="Neues Team"
required
value={teamId}
onChange={setTeamId}
placeholder="Bitte wählen…"
options={teamsInDivision.map((t) => ({ value: t.id, label: t.name }))}
/>
<TextField
label="Neuer Titel (optional)"
value={newTitle}
onChange={setNewTitle}
placeholder={employee.job_title}
hint="Die neue Führungskraft wird automatisch anhand des Zielteams bestimmt."
/>
{options.length === 0 ? (
<p className="rounded border border-border bg-surface p-3 text-sm text-ink-body">
Es gibt derzeit keine unbesetzte Planstelle. Eine Versetzung setzt eine freie Zielplanstelle voraus — legen Sie
zuerst unter „Positionen“ eine an.
</p>
) : (
<>
<SelectField
label="Zielplanstelle"
required
value={positionId}
onChange={setPositionId}
placeholder="Bitte wählen…"
options={options}
/>
{selected && (
<div className="rounded border border-border bg-surface p-3 text-sm text-ink-body">
<div className="font-semibold text-ink">{selected.title}</div>
<div className="text-xs text-ink-muted">{selected.orgLabel}</div>
<div className="mt-1 text-xs text-ink-muted">
{selected.is_chief ? "Leitungsplanstelle" : "Mitarbeiterplanstelle"}
{selected.managerName ? ` · berichtet an ${selected.managerName}` : ""}
</div>
</div>
)}
</>
)}
</div>
</SlideOver>
);

View File

@@ -0,0 +1,270 @@
"use client";
import { MessageSquarePlus, Printer } from "lucide-react";
import Link from "next/link";
import { useRouter } from "next/navigation";
import { useState } from "react";
import { Button, LINK_BUTTON_CLASS } from "@/components/ui/Button";
import { useToast } from "@/components/ui/Toast";
import {
alleReichungen,
fortschrittVon,
istErledigt,
type AufgabenGruppe,
type AufgabenPunkt,
type AufgabenStand,
} from "@/lib/checklist";
import { fmtDate } from "@/lib/format";
import type { ActionResult } from "@/lib/db/rpc";
// Die Checkliste, die bisher ein Blatt Papier war — geteilt zwischen
// Onboarding und Offboarding. Beide sind dieselbe Sache mit anderen Punkten:
// eine Liste, die sich abhaken, mit Ja/Nein beantworten oder mit einem Wert
// füllen lässt, mit Kommentar, und mit einem Vermerk, **wer** wann etwas
// eingetragen hat — auf dem Blatt stand nur ein Haken.
//
// Gespeichert wird beim Klick, nicht beim Absenden. Eine Checkliste wird über
// Tage abgearbeitet, oft zwischen zwei anderen Dingen; ein „Speichern"-Knopf
// am Ende wäre die Stelle, an der ein halber Vormittag verlorengeht.
type Props = {
gruppen: readonly AufgabenGruppe[];
staende: AufgabenStand[];
/** Ob überhaupt eine Liste existiert. */
vorhanden: boolean;
/** Text, solange keine Liste existiert. */
leerText: string;
anlegenLabel: string;
/** Ziel für den Ausdruck — eine eigene Seite, siehe PrintChecklist. */
druckHref: string;
onSpeichern: (
itemKey: string,
teil: { erledigt?: boolean; wert?: string | null; kommentar?: string | null }
) => Promise<ActionResult>;
onAnlegen: () => Promise<ActionResult>;
};
export function ChecklistPanel({
gruppen,
staende,
vorhanden,
leerText,
anlegenLabel,
druckHref,
onSpeichern,
onAnlegen,
}: Props) {
const { showToast } = useToast();
const router = useRouter();
const [laeuft, setLaeuft] = useState<string | null>(null);
const [kommentarOffen, setKommentarOffen] = useState<Set<string>>(new Set());
const punkte = alleReichungen(gruppen);
const karte = new Map(staende.map((s) => [s.item_key, s]));
const stand = fortschrittVon(punkte, staende);
async function speichern(key: string, teil: { erledigt?: boolean; wert?: string | null; kommentar?: string | null }) {
setLaeuft(key);
const ergebnis = await onSpeichern(key, teil);
setLaeuft(null);
if (ergebnis.success) router.refresh();
else showToast(ergebnis.error ?? "Konnte nicht gespeichert werden.", "error");
}
async function listeAnlegen() {
setLaeuft("neu");
const ergebnis = await onAnlegen();
setLaeuft(null);
if (ergebnis.success) {
showToast("Checkliste angelegt.");
router.refresh();
} else {
showToast(ergebnis.error ?? "Konnte nicht angelegt werden.", "error");
}
}
if (!vorhanden) {
return (
<div className="flex flex-col items-start gap-3">
<p className="text-sm text-ink-body">{leerText}</p>
<Button onClick={listeAnlegen} pending={laeuft === "neu"}>
{anlegenLabel}
</Button>
</div>
);
}
const anteil = Math.round((stand.erledigt / stand.gesamt) * 100);
return (
<div className="flex flex-col gap-6">
<div className="flex justify-end">
{/* Neuer Tab: der Ausdruck ist eine eigene Seite, und wer ihn schliesst,
steht wieder in der Akte statt auf einer leeren Historie. */}
<Link href={druckHref} target="_blank" className={LINK_BUTTON_CLASS}>
<Printer className="h-4 w-4" />
Als PDF speichern
</Link>
</div>
<div className="rounded border border-border bg-surface px-3 py-2.5">
<div className="flex flex-wrap items-baseline justify-between gap-2">
<span className="text-sm font-semibold text-ink">
{stand.erledigt} von {stand.gesamt} erledigt
</span>
<span className="text-xs text-ink-muted">
{stand.offen.length === 0 ? "Vollständig." : `Offen: ${stand.offen.slice(0, 3).join(", ")}`}
{stand.offen.length > 3 ? ` und ${stand.offen.length - 3} weitere` : ""}
</span>
</div>
<div className="mt-2 h-1.5 overflow-hidden rounded-full bg-white">
<div
className={`h-full rounded-full ${anteil === 100 ? "bg-success-text" : "bg-brand-500"}`}
style={{ width: `${Math.max(2, anteil)}%` }}
/>
</div>
</div>
{gruppen.map((gruppe) => (
<div key={gruppe.key}>
<h3 className="text-xs font-bold uppercase tracking-wide text-ink-muted">{gruppe.label}</h3>
<ul className="mt-2 flex flex-col divide-y divide-border-subtle">
{gruppe.punkte.map((punkt) => (
<Zeile
key={punkt.key}
punkt={punkt}
stand={karte.get(punkt.key)}
laeuft={laeuft === punkt.key}
kommentarOffen={kommentarOffen.has(punkt.key)}
onKommentarOeffnen={() =>
setKommentarOffen((prev) => {
const next = new Set(prev);
next.add(punkt.key);
return next;
})
}
onSpeichern={(teil) => speichern(punkt.key, teil)}
/>
))}
</ul>
</div>
))}
</div>
);
}
function Zeile({
punkt,
stand,
laeuft,
kommentarOffen,
onKommentarOeffnen,
onSpeichern,
}: {
punkt: AufgabenPunkt;
stand: AufgabenStand | undefined;
laeuft: boolean;
kommentarOffen: boolean;
onKommentarOeffnen: () => void;
onSpeichern: (teil: { erledigt?: boolean; wert?: string | null; kommentar?: string | null }) => void;
}) {
const erledigt = istErledigt(punkt, stand);
const [text, setText] = useState(stand?.wert ?? "");
const [kommentar, setKommentar] = useState(stand?.kommentar ?? "");
const zeigeKommentar = kommentarOffen || Boolean(stand?.kommentar);
return (
<li className="py-2.5">
<div className="flex flex-wrap items-center gap-x-3 gap-y-1.5">
<div className="min-w-0 flex-1">
<span className={`text-sm ${erledigt ? "text-ink-muted line-through decoration-ink-muted/40" : "text-ink"}`}>
{punkt.label}
</span>
{punkt.hinweis && <span className="block text-xs text-ink-muted">{punkt.hinweis}</span>}
</div>
{punkt.art === "haken" && (
<input
type="checkbox"
aria-label={punkt.label}
checked={stand?.erledigt ?? false}
disabled={laeuft}
onChange={(e) => onSpeichern({ erledigt: e.target.checked })}
className="h-4 w-4 shrink-0 rounded border-border text-brand-600
focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500"
/>
)}
{punkt.art === "janein" && (
// Zwei Knöpfe statt eines Hakens: „nein" ist ein erhobener Befund,
// „noch nicht gefragt" nicht. Ein Haken könnte das nicht sagen.
<span className="flex shrink-0 gap-1">
{(["ja", "nein"] as const).map((wert) => (
<button
key={wert}
type="button"
disabled={laeuft}
aria-pressed={stand?.wert === wert}
onClick={() => onSpeichern({ wert: stand?.wert === wert ? null : wert })}
className={`rounded-full px-2.5 py-0.5 text-xs font-semibold focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500 ${
stand?.wert === wert ? "bg-brand-500 text-white" : "bg-surface text-ink-muted hover:text-ink"
}`}
>
{wert === "ja" ? "Ja" : "Nein"}
</button>
))}
</span>
)}
{punkt.art === "text" && (
<input
type="text"
aria-label={`${punkt.label} — Wert`}
value={text}
disabled={laeuft}
onChange={(e) => setText(e.target.value)}
onBlur={() => text !== (stand?.wert ?? "") && onSpeichern({ wert: text || null })}
placeholder="Wert"
className="w-28 shrink-0 rounded border border-border px-2 py-1 text-sm text-ink
focus-visible:outline-2 focus-visible:outline-offset-1 focus-visible:outline-brand-500"
/>
)}
{!zeigeKommentar && (
<button
type="button"
onClick={onKommentarOeffnen}
aria-label={`Kommentar zu ${punkt.label}`}
className="shrink-0 rounded p-1 text-ink-muted hover:bg-brand-50 hover:text-brand-700
focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500"
>
<MessageSquarePlus className="h-3.5 w-3.5" />
</button>
)}
</div>
{zeigeKommentar && (
<input
type="text"
aria-label={`Kommentar zu ${punkt.label}`}
value={kommentar}
disabled={laeuft}
onChange={(e) => setKommentar(e.target.value)}
onBlur={() => kommentar !== (stand?.kommentar ?? "") && onSpeichern({ kommentar: kommentar || null })}
placeholder="Kommentar …"
className="mt-1.5 w-full rounded border border-border bg-surface px-2 py-1 text-xs text-ink-body
focus-visible:outline-2 focus-visible:outline-offset-1 focus-visible:outline-brand-500"
/>
)}
{/* Wer und wann — der Unterschied zum Blatt Papier, auf dem nur der
Haken stand. */}
{stand?.updated_by_name && (erledigt || stand.kommentar) && (
<p className="mt-1 text-[11px] text-ink-muted">
{stand.updated_by_name}
{stand.updated_at ? ` · ${fmtDate(stand.updated_at)}` : ""}
</p>
)}
</li>
);
}

View File

@@ -1,35 +1,208 @@
import { actionBadgeStyle } from "@/lib/colors";
"use client";
import { useState } from "react";
import { HistorieBearbeiten } from "@/components/employees/HistorieBearbeiten";
import { HistorieLoeschen } from "@/components/employees/HistorieLoeschen";
import { AenderungsTabelle } from "@/components/ui/AenderungsTabelle";
import { TextField } from "@/components/ui/Field";
import { SegmentedControl } from "@/components/ui/SegmentedControl";
import { eventBadgeStyle } from "@/lib/colors";
import { fmtDate, todayIso } from "@/lib/format";
import type { Database } from "@/lib/supabase/types";
import { darfBearbeitetWerden, darfKorrigiertWerden, loeschVorschau } from "@/lib/history";
import type { Database } from "@/lib/types";
type HistoryRow = Database["public"]["Tables"]["employee_history"]["Row"];
export function HistorieTab({ history }: { history: HistoryRow[] }) {
// Die Geschichte einer Person — aufklappbar bis auf die Werte, filterbar, und
// dort, wo ein Eintrag irrtümlich entstanden ist, auch zurücknehmbar.
//
// Vorher stand hier nur „Geänderte Felder: Adresse, Ort". Damit liess sich
// zwar sehen, *dass* jemand die Anschrift angefasst hat, aber nicht, was
// vorher dort stand. Die alte Adresse lag allein im Protokoll, und das ist
// eine andere Seite, nach Zeitpunkt sortiert statt nach Person — man hätte
// also erst wissen müssen, wonach man sucht.
//
// Aufgeklappt wird mit <details>, nicht mit einem Zustand im Browser: die
// Werte stehen dann schon in der Seite, sind durchsuchbar (Strg+F) und im
// Ausdruck sichtbar, und es braucht kein Skript dafür.
//
// Die Knöpfe erscheinen nur an Einträgen, wo sie etwas bewirken können. An
// allen anderen steht stattdessen der Grund — leise, aber lesbar. Ein Knopf,
// der erst nach dem Klick sagt „geht nicht", wäre eine Falle; ein fehlender
// Knopf ohne Erklärung wäre ein Rätsel.
type Sicht = "alle" | "anstehend" | "erledigt";
const SICHTEN: { value: Sicht; label: string }[] = [
{ value: "alle", label: "Alle" },
{ value: "anstehend", label: "Anstehend" },
{ value: "erledigt", label: "Vergangen" },
];
export function HistorieTab({ history, employeeId }: { history: HistoryRow[]; employeeId: string }) {
const today = todayIso();
const [sicht, setSicht] = useState<Sicht>("alle");
const [von, setVon] = useState("");
const [bis, setBis] = useState("");
// Ereignistypen, die in dieser Akte überhaupt vorkommen — eine Auswahl aus
// elf Typen, von denen zehn nie auftauchen, wäre nur Suchaufwand.
const vorhandeneTypen = [...new Set(history.map((h) => h.event_type))];
const [typen, setTypen] = useState<Set<string>>(new Set());
const gefiltert = history.filter((h) => {
if (sicht === "anstehend" && h.event_date <= today) return false;
if (sicht === "erledigt" && h.event_date > today) return false;
if (von && h.event_date < von) return false;
if (bis && h.event_date > bis) return false;
if (typen.size > 0 && !typen.has(h.event_type)) return false;
return true;
});
const anstehend = history.filter((h) => h.event_date > today).length;
const eingeschraenkt = sicht !== "alle" || Boolean(von) || Boolean(bis) || typen.size > 0;
function typUmschalten(typ: string) {
setTypen((prev) => {
const next = new Set(prev);
if (next.has(typ)) next.delete(typ);
else next.add(typ);
return next;
});
}
function zuruecksetzen() {
setSicht("alle");
setVon("");
setBis("");
setTypen(new Set());
}
if (history.length === 0) {
return <p className="text-sm text-ink-muted">Keine Historieneinträge vorhanden.</p>;
}
return (
<ul className="flex flex-col divide-y divide-border">
{history.map((h) => {
const isFuture = h.event_date > today;
return (
<li key={h.id} className="py-3">
<div className="flex flex-wrap items-center gap-2">
<span className={`rounded-full px-2 py-0.5 text-xs font-semibold ${actionBadgeStyle(h.event_type)}`}>{h.event_type}</span>
<span className="text-sm text-ink-muted">{fmtDate(h.event_date)}</span>
{isFuture && (
<span className="rounded-full bg-warning-bg px-2 py-0.5 text-xs font-semibold text-warning-text">
⏱ zukünftig – wirksam ab {fmtDate(h.event_date)}
</span>
)}
</div>
<p className="mt-1 text-sm text-ink">{h.description}</p>
</li>
);
})}
</ul>
<div className="flex flex-col gap-4">
<div className="flex flex-col gap-3 rounded border border-border bg-surface px-3 py-2.5">
<div className="flex flex-wrap items-center gap-3">
<SegmentedControl<Sicht> value={sicht} onChange={setSicht} options={SICHTEN} />
{/* Was noch kommt, ist der häufigste Grund, hier hereinzusehen —
deshalb steht die Zahl da, auch ohne dass jemand filtert. */}
{anstehend > 0 && (
<span className="rounded-full bg-warning-bg px-2 py-0.5 text-xs font-semibold text-warning-text">
{anstehend} anstehend
</span>
)}
<div className="ml-auto flex items-end gap-2">
<TextField label="Von" dense type="date" value={von} onChange={setVon} className="w-40" />
<TextField label="Bis" dense type="date" value={bis} onChange={setBis} className="w-40" />
</div>
</div>
{vorhandeneTypen.length > 1 && (
<div className="flex flex-wrap items-center gap-1.5">
{vorhandeneTypen.map((typ) => (
<button
key={typ}
type="button"
onClick={() => typUmschalten(typ)}
aria-pressed={typen.has(typ)}
className={`rounded-full px-2 py-0.5 text-xs font-semibold focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500 ${
typen.has(typ) ? eventBadgeStyle(typ) : "bg-white text-ink-muted hover:text-ink"
}`}
>
{typ}
</button>
))}
{eingeschraenkt && (
<button
type="button"
onClick={zuruecksetzen}
className="ml-auto rounded text-xs text-ink-muted hover:text-ink hover:underline focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500"
>
Filter zurücksetzen
</button>
)}
</div>
)}
</div>
{gefiltert.length === 0 ? (
<p className="text-sm text-ink-muted">
Kein Eintrag passt zu dieser Auswahl. {history.length} {history.length === 1 ? "Eintrag" : "Einträge"} sind
vorhanden.
</p>
) : (
<ul className="flex flex-col divide-y divide-border">
{gefiltert.map((h) => {
const isFuture = h.event_date > today;
const changes = h.changes ?? [];
// Die ganze Historie mitgeben, nicht die gefilterte: ob eine
// Abwesenheit gelöscht werden darf, hängt an einer späteren
// Rückkehr — auch wenn die gerade ausgeblendet ist.
const loeschbar = darfKorrigiertWerden(h, today, history);
const bearbeitbar = darfBearbeitetWerden(h, today, history);
return (
<li key={h.id} className="py-3">
<div className="flex flex-wrap items-center gap-2">
<span className={`rounded-full px-2 py-0.5 text-xs font-semibold ${eventBadgeStyle(h.event_type)}`}>
{h.event_type}
</span>
<span className="text-sm text-ink-muted">{fmtDate(h.event_date)}</span>
{isFuture && (
<span className="rounded-full bg-warning-bg px-2 py-0.5 text-xs font-semibold text-warning-text">
⏱ zukünftig – wirksam ab {fmtDate(h.event_date)}
</span>
)}
<span className="ml-auto flex items-center gap-0.5">
{bearbeitbar.erlaubt && (
<HistorieBearbeiten
historyId={h.id}
employeeId={employeeId}
bezeichnung={h.event_type}
datum={h.event_date}
changes={changes}
istZukunft={isFuture}
heute={today}
nurDatum={h.event_type === "Eintritt"}
/>
)}
{loeschbar.erlaubt && (
<HistorieLoeschen
historyId={h.id}
employeeId={employeeId}
bezeichnung={h.event_type}
datum={h.event_date}
vorschau={loeschVorschau(h, history)}
istZukunft={isFuture}
/>
)}
</span>
</div>
<p className="mt-1 text-sm text-ink">{h.description}</p>
{changes.length > 0 && (
<details className="group mt-1.5">
<summary
className="inline-flex cursor-pointer list-none items-center gap-1 rounded text-xs font-semibold text-brand-700
hover:underline focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500"
>
<span className="transition-transform group-open:rotate-90" aria-hidden="true">
›
</span>
{changes.length} {changes.length === 1 ? "Feld" : "Felder"} im Detail
</summary>
<div className="mt-2 rounded border border-border bg-surface px-3 py-2">
<AenderungsTabelle changes={changes} />
</div>
{!loeschbar.erlaubt && <p className="mt-1.5 text-xs text-ink-muted">{loeschbar.grund}</p>}
</details>
)}
</li>
);
})}
</ul>
)}
</div>
);
}

View File

@@ -8,7 +8,7 @@ import { SelectField, TextField, TextareaField } from "@/components/ui/Field";
import { useToast } from "@/components/ui/Toast";
import { NOTE_CATEGORY_STYLES } from "@/lib/colors";
import { fmtDate } from "@/lib/format";
import type { Database, NoteCategory } from "@/lib/supabase/types";
import type { Database, NoteCategory } from "@/lib/types";
type Note = Database["public"]["Tables"]["employee_notes"]["Row"];
@@ -103,7 +103,7 @@ export function NotizenTab({ employeeId, notes }: { employeeId: string; notes: N
{n.done ? (
<span className="rounded-full bg-success-bg px-2 py-0.5 text-xs font-semibold text-success-text">Erledigt</span>
) : (
<span className="rounded-full bg-brand-100 px-2 py-0.5 text-xs font-semibold text-brand-700">Offen</span>
<span className="rounded-full bg-accent-200 px-2 py-0.5 text-xs font-semibold text-brand-700">Offen</span>
)}
</div>
<p className="mt-1 text-sm text-ink">{n.note_text}</p>

View File

@@ -0,0 +1,33 @@
"use client";
import { setOffboardingTask, startOffboarding } from "@/actions/employees";
import { OFFBOARDING_GRUPPEN } from "@/lib/offboarding";
import type { AufgabenStand } from "@/lib/checklist";
import { ChecklistPanel } from "./ChecklistPanel";
// Dünne Bindung — siehe OnboardingTab.tsx, dieselbe Mechanik für den anderen
// Weg.
export function OffboardingTab({
employeeId,
staende,
vorhanden,
}: {
employeeId: string;
staende: AufgabenStand[];
/** Ob überhaupt eine Liste existiert — sie entsteht mit dem Austritt. */
vorhanden: boolean;
}) {
return (
<ChecklistPanel
gruppen={OFFBOARDING_GRUPPEN}
staende={staende}
vorhanden={vorhanden}
leerText="Für diese Person gibt es keine Offboarding-Checkliste. Für einen No Show wird keine angelegt — wer nie angetreten ist, hat nichts offzuboarden."
anlegenLabel="Checkliste anlegen"
druckHref={`/employees/${employeeId}/checkliste?art=offboarding`}
onSpeichern={(itemKey, teil) => setOffboardingTask({ employee_id: employeeId, item_key: itemKey, ...teil })}
onAnlegen={() => startOffboarding(employeeId)}
/>
);
}

View File

@@ -0,0 +1,34 @@
"use client";
import { setOnboardingTask, startOnboarding } from "@/actions/employees";
import { ONBOARDING_GRUPPEN } from "@/lib/onboarding";
import type { AufgabenStand } from "@/lib/checklist";
import { ChecklistPanel } from "./ChecklistPanel";
// Dünne Bindung: die Mechanik der Checkliste steht in ChecklistPanel, geteilt
// mit OffboardingTab. Hier steht nur, welches Verzeichnis gilt und welche
// Server-Aktionen es speichern.
export function OnboardingTab({
employeeId,
staende,
vorhanden,
}: {
employeeId: string;
staende: AufgabenStand[];
/** Ob überhaupt eine Liste existiert — sie entsteht mit dem Eintritt. */
vorhanden: boolean;
}) {
return (
<ChecklistPanel
gruppen={ONBOARDING_GRUPPEN}
staende={staende}
vorhanden={vorhanden}
leerText="Für diese Person gibt es keine Onboarding-Checkliste. Sie entsteht mit einer Einstellung oder Wiedereinstellung — wer davor eingetreten ist, hat keine."
anlegenLabel="Checkliste anlegen"
druckHref={`/employees/${employeeId}/checkliste?art=onboarding`}
onSpeichern={(itemKey, teil) => setOnboardingTask({ employee_id: employeeId, item_key: itemKey, ...teil })}
onAnlegen={() => startOnboarding(employeeId)}
/>
);
}

View File

@@ -2,23 +2,59 @@ import { Network } from "lucide-react";
import Link from "next/link";
import { Avatar } from "@/components/ui/Avatar";
import { LINK_BUTTON_CLASS } from "@/components/ui/Button";
import { fmtName } from "@/lib/format";
type MiniEmployee = { id: string; first_name: string; last_name: string; job_title: string; status?: string };
type OrganisationTabProps = {
employeeId: string;
manager: MiniEmployee | null;
/** Nur gesetzt, wenn die zuständige Leitung abwesend ist und vertreten wird. */
formalManager: MiniEmployee | null;
directReports: MiniEmployee[];
breadcrumb: string;
/**
* Die Kostenstelle der Planstelle, auf der die Person heute sitzt — nicht
* ihre eigene: sie kontiert dorthin, wo ihr Sitz kontiert ist. Fehlt sie,
* hat die Person keine laufende Besetzung (geplanter Eintritt, Austritt).
*/
kostenstelle: { code: string; name: string } | null;
};
export function OrganisationTab({ employeeId, manager, directReports, breadcrumb }: OrganisationTabProps) {
// Die Niederlassung stand hier kurzzeitig neben Einheit und Kostenstelle —
// unsere Auslegung von „Niederlassungen auch in Zuordnung einfügen"
// (Anforderung 8). Im Gespräch am 17.09.2026 hat der Kunde sie hier wieder
// gestrichen: „nimm's mal hier raus, ich glaub, da brauchen wir's nicht
// drin." Sie steht weiterhin im Vertragsblatt.
//
// Was mit der Anforderung gemeint war, ist damit weiterhin offen — siehe
// docs/rueckfragen-workshop-2026-09.md.
export function OrganisationTab({
employeeId,
manager,
formalManager,
directReports,
breadcrumb,
kostenstelle,
}: OrganisationTabProps) {
return (
<div className="flex flex-col gap-6">
<div className="flex flex-wrap items-start justify-between gap-3">
<div>
<h3 className="text-xs font-semibold uppercase tracking-wide text-ink-muted">Organisationseinheit</h3>
<p className="mt-1 text-sm text-ink">{breadcrumb}</p>
<h3 className="mt-4 text-xs font-semibold uppercase tracking-wide text-ink-muted">Kostenstelle</h3>
<p className="mt-1 text-sm text-ink">
{kostenstelle ? (
<>
<span className="font-semibold tabular-nums">{kostenstelle.code}</span>
<span className="text-ink-body"> · {kostenstelle.name}</span>
</>
) : (
<span className="text-ink-muted">Keine laufende Planstellenbesetzung</span>
)}
</p>
</div>
{/* ?focus= drives the same highlight/auto-expand path the org chart
search already uses, so the person is unfolded and centred on
@@ -30,13 +66,21 @@ export function OrganisationTab({ employeeId, manager, directReports, breadcrumb
</div>
<div>
<h3 className="mb-2 text-xs font-semibold uppercase tracking-wide text-ink-muted">Führungskraft</h3>
<h3 className="mb-2 text-xs font-semibold uppercase tracking-wide text-ink-muted">
{formalManager ? "Führungskraft (Vertretung)" : "Führungskraft"}
</h3>
{formalManager && (
<p className="mb-2 text-xs text-ink-muted">
Zuständig ist {fmtName(formalManager.first_name, formalManager.last_name)}; während der Abwesenheit übernimmt die nächste
besetzte Ebene.
</p>
)}
{manager ? (
<Link href={`/employees/${manager.id}`} className="flex w-fit items-center gap-3 rounded border border-border p-3 hover:bg-surface">
<Avatar firstName={manager.first_name} lastName={manager.last_name} />
<div>
<div className="text-sm font-semibold text-ink">
{manager.first_name} {manager.last_name}
{fmtName(manager.first_name, manager.last_name)}
</div>
<div className="text-xs text-ink-muted">{manager.job_title}</div>
</div>
@@ -55,7 +99,7 @@ export function OrganisationTab({ employeeId, manager, directReports, breadcrumb
<Avatar firstName={r.first_name} lastName={r.last_name} />
<div>
<div className="text-sm font-semibold text-ink">
{r.first_name} {r.last_name}
{fmtName(r.first_name, r.last_name)}
</div>
<div className="text-xs text-ink-muted">{r.job_title}</div>
</div>

View File

@@ -1,32 +1,65 @@
import { AngehoerigeSection } from "@/components/employees/AngehoerigeSection";
import { NotfallkontaktSection } from "@/components/employees/NotfallkontaktSection";
import { brauchtAufenthaltstitel } from "@/lib/countries";
import { fmtAge, fmtDate } from "@/lib/format";
import type { Database } from "@/lib/supabase/types";
import type { Database } from "@/lib/types";
type EmployeeRow = Database["public"]["Tables"]["employees"]["Row"];
type Location = Database["public"]["Tables"]["locations"]["Row"];
type Dependent = Database["public"]["Tables"]["employee_dependents"]["Row"];
function formatAddress(employee: EmployeeRow): string {
const cityLine = [employee.postal_code, employee.city].filter(Boolean).join(" ");
return [employee.address, cityLine].filter(Boolean).join(", ") || "–";
}
export function StammdatenTab({ employee, location, dependents }: { employee: EmployeeRow; location?: Location; dependents: Dependent[] }) {
// Defensive against a DB that hasn't received the title_prefix/title_suffix
// migration yet — select("*") simply omits unknown columns, so these can
// be undefined rather than the empty array the column default implies.
const titles = [...(employee.title_prefix ?? []), ...(employee.title_suffix ?? [])];
const prefixe = employee.title_prefix ?? [];
const suffixe = employee.title_suffix ?? [];
// Feld für Feld dieselbe Liste wie im Abschnitt „Person" von „Daten
// ändern", in derselben Reihenfolge.
//
// Vorher fasste die Anzeige zusammen: Titel in einer Zeile, Adresse mit
// Postleitzahl und Ort verschmolzen, Vor- und Nachname gar nicht — die
// standen nur in der Kopfzeile. Wer eine Angabe prüfen wollte, musste den
// Änderungsdialog öffnen, um sie überhaupt zu sehen, und stand dann schon
// in einem Formular. Was sich ändern lässt, soll sich auch ansehen lassen.
const rows: [string, string][] = [
["Titel", titles.length > 0 ? titles.join(", ") : "–"],
["Personalnummer", String(employee.personnel_number)],
["Vorname", employee.first_name],
["Nachname", employee.last_name],
["Titel (vorangestellt)", prefixe.length > 0 ? prefixe.join(", ") : "–"],
["Titel (nachgestellt)", suffixe.length > 0 ? suffixe.join(", ") : "–"],
["Geschlecht", employee.gender === "m" ? "männlich" : "weiblich"],
["Geburtsdatum", `${fmtDate(employee.birth_date)} (${fmtAge(employee.birth_date)} Jahre)`],
["SV-Nummer", employee.sv_nummer ?? "–"],
["Staatsbürgerschaft", employee.nationality],
["E-Mail", employee.email],
["Telefon", employee.phone ?? "–"],
["Standort", location ? `${location.name} (${location.country})` : "–"],
["Adresse", formatAddress(employee)],
// Nur, wo er verlangt ist. Bei einer österreichischen Staatsbürger-
// schaft wäre die Zeile „Aufenthaltstitel: Nein" keine Auskunft,
// sondern eine Frage, die sich nicht stellt.
...(brauchtAufenthaltstitel(employee.nationality)
? ([
[
"Aufenthaltstitel",
employee.hat_aufenthaltstitel
? employee.aufenthaltstitel_bis
? `Ja, bis ${fmtDate(employee.aufenthaltstitel_bis)}`
: "Ja (unbefristet oder nicht erfasst)"
: "Nein",
],
] as [string, string][])
: []),
["Adresse", employee.address ?? "–"],
["Postleitzahl", employee.postal_code ?? "–"],
["Ort", employee.city ?? "–"],
["Land", employee.address_country ?? "–"],
["Geschlecht", employee.gender === "m" ? "männlich" : "weiblich"],
["Private E-Mail", employee.email ?? "–"],
["Firmen-E-Mail", employee.company_email ?? "–"],
["Cornerstone-ID", employee.cornerstone_id ?? "–"],
["Private Telefonnummer", employee.phone ?? "–"],
// Der Standort ist keine Angabe zur Person, sondern die Betriebsstätte —
// er steht deshalb am Ende und nicht zwischen Adresse und Land, wo man
// ihn für den Wohnort halten könnte.
["Standort", location ? `${location.name} (${location.country})` : "–"],
];
return (
<div className="flex flex-col gap-6">
@@ -38,7 +71,17 @@ export function StammdatenTab({ employee, location, dependents }: { employee: Em
</div>
))}
</dl>
<AngehoerigeSection employeeId={employee.id} dependents={dependents} />
<NotfallkontaktSection
employeeId={employee.id}
kontakt={{
name: employee.emergency_contact_name,
telefon: employee.emergency_contact_phone,
verhaeltnis: employee.emergency_contact_relation,
}}
/>
</div>
);
}

View File

@@ -1,24 +1,55 @@
import { dienstwagenLabel } from "@/lib/dienstwagen";
import { fmtDate } from "@/lib/format";
import type { Database } from "@/lib/supabase/types";
import { hayGradeLabel } from "@/lib/hay-grade";
import type { Database } from "@/lib/types";
type EmployeeRow = Database["public"]["Tables"]["employees"]["Row"];
const PAYGRADE_LABELS: Record<string, string> = {
A: "A – Einstieg",
B: "B – Qualifiziert",
C: "C – Erfahren",
D: "D – Spezialist:in",
E: "E – Teamleitung",
F: "F – Bereichsleitung / GF",
};
/**
* Der Kündigungsschutz mit Grund und Zeitraum.
*
* Hier stand nur „bis TT.MM.JJJJ". Erfasst werden aber Personenkreis, Beginn
* und Ende — und der Personenkreis ist die eigentliche Auskunft: „bis 2030"
* sagt nicht, warum. Gemeldet am 29.09. von Lara und im Testprotokoll (H.09).
*
* Die Wortwahl für den einfachsten Fall bleibt: steht nur das Kennzeichen da,
* heisst es weiter „Ja (Ende offen)".
*/
function kuendigungsschutzText(e: EmployeeRow): string {
if (!e.has_kuendigungsschutz) return "Nein";
const teile = [
e.kuendigungsschutz_grund,
e.kuendigungsschutz_ab ? `ab ${fmtDate(e.kuendigungsschutz_ab)}` : null,
e.kuendigungsschutz_bis ? `bis ${fmtDate(e.kuendigungsschutz_bis)}` : null,
].filter((t): t is string => Boolean(t));
if (teile.length === 0) return "Ja (Ende offen)";
return e.kuendigungsschutz_bis ? teile.join(" · ") : `${teile.join(" · ")} · Ende offen`;
}
/**
* Die Begünstigung als eigene Zeile, nicht an den Kündigungsschutz gehängt.
*
* Sie führt zwar oft zu besonderem Kündigungsschutz, ist aber ein eigener
* Bescheid — und der Grad gehört zur Behinderung, nicht zum Schutz.
*/
function behinderungText(e: EmployeeRow): string {
if (!e.ist_beguenstigt_behindert) return "Nein";
const teile = [
e.behinderung_grad !== null ? `${e.behinderung_grad} %` : null,
e.behinderung_ab ? `Bescheid ab ${fmtDate(e.behinderung_ab)}` : null,
e.behinderung_bis ? `bis ${fmtDate(e.behinderung_bis)}` : null,
].filter((t): t is string => Boolean(t));
return teile.length > 0 ? teile.join(" · ") : "Ja";
}
export function VertragTab({ employee }: { employee: EmployeeRow }) {
const flags = [
employee.is_betriebsrat && "Betriebsrat",
employee.has_dienstwagen && "Dienstwagen",
employee.is_laterale_fuehrung && "Laterale Führung",
employee.is_c_level && "C-Level",
].filter(Boolean);
// Früher stand hier eine einzige Zeile „Merkmale" mit allem, was zutraf,
// durch Kommas getrennt — und ein Gedankenstrich, wenn nichts zutraf. Damit
// liess sich nicht ablesen, ob jemand *keinen* Dienstwagen hat oder ob
// niemand die Frage je beantwortet hat. Jedes Merkmal steht jetzt für sich,
// mit Ja oder Nein, wie jede andere Zeile auf diesem Blatt auch.
const rows: [string, string][] = [
["Eintrittsdatum", fmtDate(employee.entry_date)],
["Vertragsart", employee.contract_type === "befristet" ? `befristet bis ${fmtDate(employee.contract_end_date)}` : "unbefristet"],
@@ -26,10 +57,38 @@ export function VertragTab({ employee }: { employee: EmployeeRow }) {
["Beschäftigungsausmaß", employee.employment_type],
["Wochenstunden", `${employee.weekly_hours} h`],
["Urlaubsanspruch", "25 Tage"],
["Paygrade", PAYGRADE_LABELS[employee.paygrade] ?? employee.paygrade],
["Angestellte:r / Arbeiter:in", employee.worker_type ?? "–"],
["Hay-Grade", hayGradeLabel(employee.paygrade)],
["Beschäftigtengruppe", employee.worker_type ?? "–"],
["Arbeitstage", employee.work_days?.join(", ") || "–"],
["Merkmale", flags.length > 0 ? flags.join(", ") : "–"],
// Beim Dienstwagen steht die Antriebsart statt eines blossen „Ja" — das
// war die Frage dahinter, seit E-Fahrzeuge getrennt zu führen sind.
["Dienstwagen", employee.has_dienstwagen ? dienstwagenLabel(employee.dienstwagen_art) : "Nein"],
["Betriebsrat", employee.is_betriebsrat ? "Ja" : "Nein"],
["Laterale Führung", employee.is_laterale_fuehrung ? "Ja" : "Nein"],
["C-Level", employee.is_c_level ? "Ja" : "Nein"],
// Das Enddatum steht gleich dabei: „Ja" allein liesse offen, ob der
// Schutz noch läuft, und genau danach fragt man.
// Die Teilzeitvariante gehört neben die Stunden: sie erklärt, warum sie
// sind, wie sie sind.
[
"Teilzeitvariante",
employee.teilzeit_art
? employee.teilzeit_bis
? `${employee.teilzeit_art} bis ${fmtDate(employee.teilzeit_bis)}`
: `${employee.teilzeit_art} (Ende offen)`
: "–",
],
// Grund und Zeitraum stehen dabei, nicht nur das Enddatum. Gemeldet am
// 29.09.: erfasst werden sieben Felder — Personenkreis, Beginn, Ende,
// Behinderung mit Grad und Bescheidzeitraum —, sichtbar war in der Akte
// nur „bis TT.MM.JJJJ". Wer den Grund brauchte, fand ihn nur in der
// Historie oder über einen Bericht.
["Besonderer Kündigungsschutz", kuendigungsschutzText(employee)],
// Eigene Zeile und nicht an den Kündigungsschutz gehängt: die Begünstigung
// ist ein Bescheid für sich. Sie führt zwar oft zu besonderem
// Kündigungsschutz, ist aber nicht dasselbe, und der Grad gehört zur
// Behinderung, nicht zum Schutz.
["Begünstigt behindert", behinderungText(employee)],
];
if (employee.exit_date) rows.push(["Austrittsdatum", fmtDate(employee.exit_date)]);

View File

@@ -1,21 +1,29 @@
"use client";
import { useMemo, useState } from "react";
import { useCallback, useMemo, useState } from "react";
import { useRouter } from "next/navigation";
import { hireEmployee } from "@/actions/employees";
import { addEmployeeDependent, hireEmployee } from "@/actions/employees";
import { deleteHireDraft, saveHireDraft } from "@/actions/hireDrafts";
import { Button } from "@/components/ui/Button";
import { Modal } from "@/components/ui/Modal";
import { useToast } from "@/components/ui/Toast";
import { GRUND_BEGUENSTIGT_BEHINDERT } from "@/lib/kuendigungsschutz";
import type { OpenPositionResolved } from "@/lib/positions";
import { isValidSvnr, requiresAustrianSvnr } from "@/lib/svnr";
import { StepAngehoerige } from "./StepAngehoerige";
import { StepNotfallkontakt } from "./StepNotfallkontakt";
import { StepPerson } from "./StepPerson";
import { StepPosition } from "./StepPosition";
import { StepSummary } from "./StepSummary";
import { StepVertrag } from "./StepVertrag";
import { EMPTY_HIRE_DRAFT, type HireDraftData } from "./types";
const STEP_LABELS = ["Person", "Position", "Vertrag", "Zusammenfassung"];
// Vertrag vor Angehörige: was den Vertrag ausmacht — Eintritt, Arbeitstage,
// Befristung — steht auf dem Papier, das vor dem Gespräch da ist. Angehörige
// bringt die Person mit, oft erst am ersten Tag. Bis September 2026 stand es
// andersherum, und der freiwillige Schritt lag vor dem, der die Einstellung
// überhaupt trägt.
const STEP_LABELS = ["Person", "Position", "Vertrag", "Angehörige", "Notfallkontakt", "Zusammenfassung"] as const;
type HireWizardProps = {
open: boolean;
@@ -52,17 +60,65 @@ export function HireWizard({ open, onClose, openPositions, locations, resumeDraf
// Blocks step 1 rather than letting the hire fail at the RPC: the SVNR
// trigger rejects a bad number, and by then the user is three steps on.
// Dieselbe Überlegung wie bei der SV-Nummer, nur dass die Antwort aus der
// Datenbank kommt: eine vergebene Personalnummer wies bisher erst
// hire_employee ab — nach sechs Schritten Eingabe, und die Nummer steht im
// ersten Feld des ersten Schritts.
//
// Gemerkt wird die *Nummer*, die als vergeben zurückkam, nicht ein Ja/Nein.
// So ist die Sperre eine Ableitung aus dem, was im Feld steht, und muss
// beim Weitertippen nicht zurückgesetzt werden — ein Zurücksetzen, das man
// vergessen kann, sperrt sonst ein Formular ohne sichtbaren Grund.
const [vergebeneNummer, setVergebeneNummer] = useState<number | null>(null);
const nummerFrei = Number(draft.personnelNumber) !== vergebeneNummer;
const merkeBefund = useCallback(
(befund: { nummer: number; vergeben: boolean }) => setVergebeneNummer(befund.vergeben ? befund.nummer : null),
[]
);
const svNummerOk =
!draft.svNummer.trim() ||
!requiresAustrianSvnr(locations.find((l) => l.id === draft.locationId)?.country) ||
isValidSvnr(draft.svNummer, draft.birthDate || null);
const stepValid = [
Boolean(draft.firstName && draft.lastName && draft.birthDate && draft.locationId) && svNummerOk,
Boolean(draft.positionId && draft.besetzung),
Boolean(draft.entryDate && draft.workDays.length > 0),
true,
][step];
// Am Namen des Schritts, nicht an seiner Nummer.
//
// Vorher war das eine Liste in derselben Reihenfolge wie STEP_LABELS, und
// die beiden mussten stumm zusammenpassen. Beim Vertauschen von Vertrag und
// Angehörige wäre die Prüfung stehengeblieben, wo sie war: „Weiter" im
// Vertrag hätte die Angehörigen geprüft und ein leeres Eintrittsdatum
// durchgelassen — bis die Datenbank es am Ende abweist.
const pruefung: Record<(typeof STEP_LABELS)[number], boolean> = {
// E-Mail gehört zu den Pflichtfeldern, weil die Spalte NOT NULL ist. Ohne
// die Prüfung hier bricht erst die Datenbank ab — nach allen Eingaben.
// Die private E-Mail-Adresse steht bewusst nicht mehr darunter: sie ist
// freiwillig, seit die Spalte NULL zulässt.
Person:
Boolean(
draft.personnelNumber.trim() && draft.firstName && draft.lastName && draft.birthDate && draft.locationId
) && svNummerOk && nummerFrei,
Position: Boolean(draft.positionId && draft.besetzung),
Vertrag: Boolean(draft.entryDate && draft.workDays.length > 0),
// Angehörige: freiwillig — aber eine begonnene Zeile muss vollständig
// sein, sonst scheitert sie erst nach dem Anlegen der Person, und die
// steht dann schon in der Datenbank.
Angehörige: draft.angehoerige.every(
(a) =>
a.firstName.trim() &&
a.lastName.trim() &&
a.birthDate &&
(!a.svNummer.trim() || isValidSvnr(a.svNummer, a.birthDate || null))
),
// Notfallkontakt: freiwillig, aber Name und Nummer nur gemeinsam — die
// Datenbank weist eines ohne das andere ab (chk_emergency_contact).
Notfallkontakt:
Boolean(draft.emergencyContactName.trim()) === Boolean(draft.emergencyContactPhone.trim()),
Zusammenfassung: true,
};
const stepValid = pruefung[STEP_LABELS[step]];
/** Der letzte Schritt; von hier wird angelegt statt weitergeblättert. */
const letzterSchritt = STEP_LABELS.length - 1;
async function handleSaveDraft() {
const result = await saveHireDraft({ id: draftId, step, data: draft });
@@ -77,8 +133,13 @@ export function HireWizard({ open, onClose, openPositions, locations, resumeDraf
async function handleSubmit() {
if (!selectedPosition || !draft.besetzung) return;
// Dieselbe Regel wie im Formular (RoleEmploymentFields): der
// Personenkreis zieht das Kennzeichen mit. Was gezeigt wurde, muss auch
// abgeschickt werden.
const istBehindert = draft.istBeguenstigtBehindert || draft.kuendigungsschutzGrund === GRUND_BEGUENSTIGT_BEHINDERT;
setSubmitting(true);
const result = await hireEmployee({
personnel_number: Number(draft.personnelNumber),
first_name: draft.firstName,
last_name: draft.lastName,
title_prefix: draft.titlePrefix,
@@ -86,6 +147,9 @@ export function HireWizard({ open, onClose, openPositions, locations, resumeDraf
gender: draft.gender,
birth_date: draft.birthDate,
sv_nummer: draft.svNummer || undefined,
email: draft.email.trim() || undefined,
company_email: draft.companyEmail.trim() || undefined,
cornerstone_id: draft.cornerstoneId.trim() || undefined,
phone: draft.phone || undefined,
position_id: draft.positionId,
location_id: draft.locationId,
@@ -101,17 +165,65 @@ export function HireWizard({ open, onClose, openPositions, locations, resumeDraf
work_days: draft.workDays,
is_betriebsrat: draft.isBetriebsrat,
has_dienstwagen: draft.hasDienstwagen,
// Null, sobald kein Dienstwagen da ist — der CHECK lässt die Angabe
// sonst nicht zu.
dienstwagen_art: draft.hasDienstwagen ? draft.dienstwagenArt : null,
mitarbeiterart: draft.mitarbeiterart,
has_kuendigungsschutz: draft.hasKuendigungsschutz,
// Ohne Schutz kein Enddatum, kein Beginn, kein Personenkreis — die
// CHECKs lassen es nicht anders zu.
kuendigungsschutz_bis: draft.hasKuendigungsschutz ? draft.kuendigungsschutzBis || null : null,
kuendigungsschutz_grund: draft.hasKuendigungsschutz ? draft.kuendigungsschutzGrund || null : null,
kuendigungsschutz_ab: draft.hasKuendigungsschutz ? draft.kuendigungsschutzAb || null : null,
ist_beguenstigt_behindert: istBehindert,
behinderung_grad: istBehindert ? draft.behinderungGrad || null : null,
behinderung_ab: istBehindert ? draft.behinderungAb || null : null,
behinderung_bis: istBehindert ? draft.behinderungBis || null : null,
emergency_contact_name: draft.emergencyContactName.trim() || undefined,
emergency_contact_phone: draft.emergencyContactPhone.trim() || undefined,
emergency_contact_relation: draft.emergencyContactRelation.trim() || undefined,
is_laterale_fuehrung: draft.isLateraleFuehrung,
is_c_level: draft.isCLevel,
});
setSubmitting(false);
if (result.success) {
showToast(`${draft.firstName} ${draft.lastName} wurde eingestellt.`);
if (draftId) await deleteHireDraft(draftId);
router.refresh();
onClose();
} else {
if (!result.success || !result.employeeId) {
setSubmitting(false);
showToast(result.error ?? "Fehler beim Anlegen.", "error");
return;
}
// Angehörige erst jetzt: add_employee_dependent braucht die Kennung, und
// die entsteht mit der Einstellung.
//
// Damit hängen sie ausserhalb der Transaktion, in der die Person
// entsteht. Scheitert eine, ist die Person trotzdem angelegt — deshalb
// wird nicht stillschweigend weitergemacht, sondern genau gesagt, wer
// fehlt. Nachtragen geht in der Personalakte.
const gescheitert: string[] = [];
for (const a of draft.angehoerige) {
const r = await addEmployeeDependent({
employee_id: result.employeeId,
first_name: a.firstName.trim(),
last_name: a.lastName.trim(),
relationship: a.relationship,
birth_date: a.birthDate,
sv_nummer: a.svNummer.trim() || undefined,
effective_date: draft.entryDate,
});
if (!r.success) gescheitert.push(`${a.firstName} ${a.lastName}`.trim());
}
setSubmitting(false);
if (draftId) await deleteHireDraft(draftId);
router.refresh();
onClose();
if (gescheitert.length > 0) {
showToast(
`${draft.firstName} ${draft.lastName} wurde eingestellt, aber ${gescheitert.join(", ")} konnte nicht als Angehörige:r angelegt werden — bitte in der Personalakte nachtragen.`,
"error"
);
} else {
showToast(`${draft.firstName} ${draft.lastName} wurde eingestellt.`);
}
}
@@ -137,12 +249,12 @@ export function HireWizard({ open, onClose, openPositions, locations, resumeDraf
Zurück
</Button>
)}
{step < 3 && (
{step < letzterSchritt && (
<Button onClick={() => setStep((s) => s + 1)} disabled={!stepValid}>
Weiter
</Button>
)}
{step === 3 && (
{step === letzterSchritt && (
<Button onClick={handleSubmit} pending={submitting}>
Anlegen
</Button>
@@ -174,10 +286,12 @@ export function HireWizard({ open, onClose, openPositions, locations, resumeDraf
))}
</div>
{step === 0 && <StepPerson draft={draft} update={update} locations={locations} />}
{step === 0 && <StepPerson draft={draft} update={update} locations={locations} onNummerBefund={merkeBefund} />}
{step === 1 && <StepPosition draft={draft} update={update} openPositions={openPositions} />}
{step === 2 && <StepVertrag draft={draft} update={update} />}
{step === 3 && <StepSummary draft={draft} selectedPosition={selectedPosition} locations={locations} />}
{step === 3 && <StepAngehoerige draft={draft} update={update} />}
{step === 4 && <StepNotfallkontakt draft={draft} update={update} />}
{step === 5 && <StepSummary draft={draft} selectedPosition={selectedPosition} locations={locations} />}
</Modal>
);
}

View File

@@ -1,11 +1,14 @@
"use client";
import { createContext, useContext, useState, type ReactNode } from "react";
import { useRouter } from "next/navigation";
import { createContext, useContext, useEffect, useRef, useState, type ReactNode } from "react";
import { entwurfFreigeben, entwurfSperren } from "@/actions/hireDrafts";
import { useToast } from "@/components/ui/Toast";
import type { Entwurf } from "@/lib/entwuerfe";
import type { OpenPositionResolved } from "@/lib/positions";
import { HireWizard } from "./HireWizard";
type Location = { id: string; name: string; country: string };
type HireDraft = { id: string; step: number; payload: Record<string, unknown> };
type OpenWizardOptions = { draftId?: string; positionId?: string };
@@ -15,6 +18,16 @@ type HireWizardContextValue = {
const HireWizardContext = createContext<HireWizardContextValue | null>(null);
/**
* Wie oft die Sperre aufgefrischt wird, solange der Assistent offen ist.
*
* Deutlich kürzer als die Frist in der Datenbank (15 Minuten,
* app_entwurf_sperrfrist): zwischen zwei Takten darf eine Antwort ausfallen,
* ohne dass die Sperre wegläuft. Wer eine halbe Stunde an einem Entwurf
* sitzt, soll ihn nicht auf halbem Weg an eine Kollegin verlieren.
*/
const TAKT_MS = 5 * 60 * 1000;
export function HireWizardProvider({
children,
openPositions,
@@ -24,10 +37,12 @@ export function HireWizardProvider({
children: ReactNode;
openPositions: OpenPositionResolved[];
locations: Location[];
drafts: HireDraft[];
drafts: Entwurf[];
}) {
const { showToast } = useToast();
const router = useRouter();
const [open, setOpen] = useState(false);
const [resumeDraft, setResumeDraft] = useState<HireDraft | null>(null);
const [resumeDraft, setResumeDraft] = useState<Entwurf | null>(null);
const [initialPositionId, setInitialPositionId] = useState<string | undefined>(undefined);
// Forces HireWizard to remount fresh each time it's opened, so its
// internal draft/step state is (re-)initialized directly from the current
@@ -35,20 +50,73 @@ export function HireWizardProvider({
// effect needed inside HireWizard itself.
const [openKey, setOpenKey] = useState(0);
function openWizard(options?: OpenWizardOptions) {
// Die Kennung des Entwurfs, dessen Sperre wir halten. Als Ref, weil sie im
// Aufräumen des Effekts gebraucht wird — über den Zustand gelesen wäre es
// dort der Stand von vorhin.
const gesperrt = useRef<string | null>(null);
async function openWizard(options?: OpenWizardOptions) {
// Ohne Entwurf gibt es nichts zu sperren: eine neue Einstellung entsteht
// erst beim Speichern.
if (options?.draftId) {
const result = await entwurfSperren(options.draftId);
if (!result.success) {
showToast(result.error ?? "Der Entwurf lässt sich gerade nicht öffnen.", "error");
// Die Liste holt sich den Stand: wer die Sperre hält, steht danach
// an der Zeile, statt dass nur eine Meldung aufblitzt.
router.refresh();
return;
}
gesperrt.current = options.draftId;
}
setResumeDraft(options?.draftId ? (drafts.find((d) => d.id === options.draftId) ?? null) : null);
setInitialPositionId(options?.positionId);
setOpen(true);
setOpenKey((k) => k + 1);
}
function closeWizard() {
setOpen(false);
freigeben();
}
function freigeben() {
const id = gesperrt.current;
if (!id) return;
gesperrt.current = null;
void entwurfFreigeben(id);
}
// Auffrischen, solange der Assistent offen ist. Ohne das liefe die Frist
// einem langen Ausfüllen davon, und das Speichern am Ende fände seine
// eigene Sperre abgelaufen.
//
// `!open` ist doppelt gemoppelt: freigeben() räumt beim Zumachen auch
// gesperrt.current weg, und daran scheitert der Takt ohnehin. Es steht
// trotzdem da, weil es die Bedingung ausspricht, um die es geht — dass
// nach dem Zumachen nichts mehr aufgefrischt wird, hängt sonst an einer
// Zuweisung drei Funktionen weiter oben.
useEffect(() => {
if (!open || !gesperrt.current) return;
const timer = setInterval(() => {
if (gesperrt.current) void entwurfSperren(gesperrt.current);
}, TAKT_MS);
return () => clearInterval(timer);
}, [open, openKey]);
// Beim Verlassen der Seite: dieselbe Freigabe wie beim Schliessen. Sie
// erreicht den Server nicht immer — ein zugeklappter Laptop schickt nichts
// mehr. Deshalb ist sie die Höflichkeit und nicht die Absicherung; die
// Absicherung ist die Frist in der Datenbank.
useEffect(() => () => freigeben(), []);
return (
<HireWizardContext.Provider value={{ openWizard }}>
{children}
<HireWizard
key={openKey}
open={open}
onClose={() => setOpen(false)}
onClose={closeWizard}
openPositions={openPositions}
locations={locations}
resumeDraft={resumeDraft}

View File

@@ -0,0 +1,99 @@
"use client";
import { useEffect, useRef, useState } from "react";
import { personalnummerVergeben } from "@/actions/employees";
import { TextField } from "@/components/ui/Field";
// Die Personalnummer wird eingegeben, nicht vergeben — sie muss mit Loga und
// Interflex übereinstimmen. Genau deshalb kommt sie von aussen, und genau
// deshalb kann sie schon vergeben sein: an dieselbe Person, die jemand ein
// zweites Mal anlegt, oder an eine ganz andere nach einem Zahlendreher.
//
// Die Datenbank weist das ab (hire_employee prüft es eigens), aber erst beim
// Anlegen — nach sechs Schritten Eingabe. Bis dahin ist die falsche Nummer
// schon durch alle Formulare gereist.
//
// ── Wann gefragt wird ───────────────────────────────────────────────
//
// Nicht bei jedem Tastendruck: „3", „34", „347" wären drei Fragen an die
// Datenbank für eine Eingabe, und die ersten beiden hätten eine Antwort auf
// eine Nummer, die niemand meint. Stattdessen eine halbe Sekunde Ruhe
// abwarten — lange genug, dass eine vierstellige Nummer am Stück eingetippt
// eine einzige Frage ergibt, kurz genug, dass die Antwort da ist, bevor der
// Blick zum nächsten Feld wandert.
//
// Die Antwort kann veralten, während sie unterwegs ist. Deshalb zählt jede
// Anfrage mit und nur die jüngste darf schreiben: sonst überschriebe die
// langsamere Antwort auf „347" die schnellere auf „3471".
//
// ── Warum der Befund an der Nummer hängt und nicht an einem Ja/Nein ──
//
// Gespeichert wird **die geprüfte Nummer** mitsamt ihrem Ergebnis, nicht
// bloss „frei" oder „vergeben". Damit ist jede Anzeige eine Ableitung aus
// dem, was gerade im Feld steht — es gibt keinen Zustand, der zurückgesetzt
// werden müsste, wenn die Eingabe sich ändert, und deshalb auch keine Stelle,
// an der das Zurücksetzen vergessen werden kann.
const WARTEZEIT_MS = 500;
type Befund = { nummer: number; vergeben: boolean; name?: string };
export function PersonalnummerField({
wert,
onChange,
onBefund,
}: {
wert: string;
onChange: (wert: string) => void;
/** Meldet dem Assistenten die geprüfte Nummer und ihr Ergebnis. */
onBefund: (befund: Befund) => void;
}) {
const [befund, setBefund] = useState<Befund | null>(null);
const laufendeNr = useRef(0);
const nummer = Number(wert);
const gueltig = Boolean(wert.trim()) && Number.isInteger(nummer) && nummer > 0;
// Nur ein Befund zu *dieser* Nummer zählt. Steht im Feld inzwischen etwas
// anderes, ist die alte Auskunft gegenstandslos.
const passend = gueltig && befund?.nummer === nummer ? befund : null;
const laeuft = gueltig && !passend;
useEffect(() => {
if (!gueltig) return;
const meine = ++laufendeNr.current;
const zeit = setTimeout(async () => {
let antwort: { vergeben: boolean; name?: string };
try {
antwort = await personalnummerVergeben(nummer);
} catch {
// Keine Auskunft ist kein Hindernis: die Datenbank entscheidet beim
// Anlegen ohnehin. Eine Meldung über eine gescheiterte *Vorab*-Prüfung
// wäre für die Eingebende nur Lärm.
antwort = { vergeben: false };
}
if (meine !== laufendeNr.current) return;
const neu: Befund = { nummer, ...antwort };
setBefund(neu);
onBefund(neu);
}, WARTEZEIT_MS);
return () => clearTimeout(zeit);
}, [gueltig, nummer, onBefund]);
return (
<TextField
label="Personalnummer"
required
inputMode="numeric"
value={wert}
onChange={(v) => onChange(v.replace(/\D/g, ""))}
error={
passend?.vergeben
? `Diese Personalnummer ist bereits vergeben${passend.name ? ` — an ${passend.name}` : ""}.`
: undefined
}
hint={laeuft ? "Wird geprüft…" : "Muss mit Loga und Interflex übereinstimmen. Wird nicht automatisch vergeben."}
/>
);
}

View File

@@ -0,0 +1,241 @@
"use client";
import { useRouter } from "next/navigation";
import { useMemo, useState } from "react";
import { rehireEmployee } from "@/actions/employees";
import { Button } from "@/components/ui/Button";
import { Modal } from "@/components/ui/Modal";
import { useToast } from "@/components/ui/Toast";
import { fmtName } from "@/lib/format";
import { GRUND_BEGUENSTIGT_BEHINDERT } from "@/lib/kuendigungsschutz";
import type { OpenPositionResolved } from "@/lib/positions";
import { isValidSvnr, requiresAustrianSvnr } from "@/lib/svnr";
import type { Database } from "@/lib/types";
import { vorbelegungAus } from "@/lib/wiedereintritt";
import { StepNotfallkontakt } from "./StepNotfallkontakt";
import { StepPerson } from "./StepPerson";
import { StepPosition } from "./StepPosition";
import { StepSummary } from "./StepSummary";
import { StepVertrag } from "./StepVertrag";
import { EMPTY_HIRE_DRAFT, type HireDraftData } from "./types";
type EmployeeRow = Database["public"]["Tables"]["employees"]["Row"];
// Der Wiedereintritt als Assistent — derselbe Weg wie eine Neueinstellung,
// nur vorbefüllt.
//
// ── Warum nicht der kleine Dialog von vorher ────────────────────────
//
// Der fragte Datum und Planstelle und liess alles andere stehen, wie es beim
// Austritt war. Nach zwei Jahren Abwesenheit ist das selten noch richtig: die
// Anschrift, die Wochenstunden, der Kollektivvertrag, oft auch der Name. Wer
// das bemerkte, musste die Person erst wiedereinstellen und danach „Daten
// ändern" öffnen — zwei Vorgänge für einen, und in der Akte steht dann eine
// Vertragsänderung am Tag des Wiedereintritts, die niemand vorgenommen hat.
//
// ── Warum ein eigenes Bauteil und kein Schalter im HireWizard ───────
//
// Die beiden Abläufe sehen gleich aus und sind es nicht: hier gibt es keinen
// Entwurf zu speichern, keine Angehörigen anzulegen (die stehen schon in der
// Akte), keine Personalnummer zu prüfen, und am Ende ruft er eine andere
// Funktion. Ein HireWizard mit `modus === "rehire"` an sechs Stellen wäre
// schwerer zu lesen als zwei Abläufe, die sich die Schritte teilen — und die
// Schritte sind der Teil, der wirklich geteilt gehört.
//
// ── Warum alles in einem Aufruf geht ────────────────────────────────
//
// `rehire_employee` nimmt den ganzen Satz entgegen und schreibt ihn in einer
// Transaktion (Migration 20260917130000). Erst wiedereinstellen und dann
// ändern wären zwei Transaktionen, und scheitert die zweite, steht die Person
// wieder im Dienst — mit den Daten von damals und ohne dass es jemand merkt.
const STEP_LABELS = ["Person", "Position", "Vertrag", "Notfallkontakt", "Zusammenfassung"] as const;
type RehireWizardProps = {
open: boolean;
onClose: () => void;
employee: EmployeeRow;
openPositions: OpenPositionResolved[];
locations: { id: string; name: string; country: string }[];
};
export function RehireWizard({ open, onClose, employee, openPositions, locations }: RehireWizardProps) {
const { showToast } = useToast();
const router = useRouter();
const [step, setStep] = useState(0);
// Die Akte remountet dieses Bauteil über einen wechselnden `key`, sobald es
// frisch geöffnet wird — diese Initialisierung ist damit das Zurücksetzen,
// ganz ohne Effekt.
const [draft, setDraft] = useState<HireDraftData>(() => ({
...EMPTY_HIRE_DRAFT,
...vorbelegungAus(employee),
// Planstelle und Eintrittsdatum bleiben leer: die alte Stelle kann
// besetzt oder entfallen sein, und das neue Datum ist die eigentliche
// Angabe dieses Vorgangs. Siehe lib/wiedereintritt.ts.
positionId: "",
entryDate: "",
angehoerige: [],
}));
const [submitting, setSubmitting] = useState(false);
const selectedPosition = useMemo(
() => openPositions.find((p) => p.id === draft.positionId) ?? null,
[openPositions, draft.positionId]
);
function update(patch: Partial<HireDraftData>) {
setDraft((prev) => ({ ...prev, ...patch }));
}
const svNummerOk =
!draft.svNummer.trim() ||
!requiresAustrianSvnr(locations.find((l) => l.id === draft.locationId)?.country) ||
isValidSvnr(draft.svNummer, draft.birthDate || null);
// Dieselben Bedingungen wie bei einer Neueinstellung, abzüglich der
// Personalnummer: sie steht fest und wird nicht geprüft.
const pruefung: Record<(typeof STEP_LABELS)[number], boolean> = {
Person: Boolean(draft.firstName && draft.lastName && draft.birthDate && draft.locationId) && svNummerOk,
Position: Boolean(draft.positionId && draft.besetzung),
Vertrag: Boolean(draft.entryDate && draft.workDays.length > 0),
Notfallkontakt: Boolean(draft.emergencyContactName.trim()) === Boolean(draft.emergencyContactPhone.trim()),
Zusammenfassung: true,
};
const stepValid = pruefung[STEP_LABELS[step]];
const letzterSchritt = STEP_LABELS.length - 1;
async function handleSubmit() {
if (!draft.positionId || !draft.entryDate) return;
// Dieselbe Regel wie im Formular: der Personenkreis zieht das Kennzeichen
// mit. Was gezeigt wurde, muss auch abgeschickt werden.
const istBehindert = draft.istBeguenstigtBehindert || draft.kuendigungsschutzGrund === GRUND_BEGUENSTIGT_BEHINDERT;
setSubmitting(true);
const result = await rehireEmployee({
employee_id: employee.id,
rehire_date: draft.entryDate,
position_id: draft.positionId,
first_name: draft.firstName,
last_name: draft.lastName,
title_prefix: draft.titlePrefix,
title_suffix: draft.titleSuffix,
gender: draft.gender,
birth_date: draft.birthDate,
sv_nummer: draft.svNummer.trim(),
email: draft.email.trim(),
company_email: draft.companyEmail.trim(),
cornerstone_id: draft.cornerstoneId.trim(),
phone: draft.phone.trim(),
location_id: draft.locationId,
// Anschrift, Staatsbürgerschaft und Aufenthaltstitel stehen bewusst
// nicht hier: der Assistent zeigt sie nicht, und was er nicht zeigt,
// darf er nicht schicken. rehire_employee lässt jedes nicht
// übermittelte Feld unangetastet stehen.
emergency_contact_name: draft.emergencyContactName.trim(),
emergency_contact_phone: draft.emergencyContactPhone.trim(),
emergency_contact_relation: draft.emergencyContactRelation.trim(),
employment_type: draft.employmentType,
weekly_hours: Number(draft.weeklyHours),
contract_type: draft.contractType,
contract_end_date: draft.contractEndDate,
paygrade: draft.paygrade,
source: draft.besetzung,
worker_type: draft.workerType,
mitarbeiterart: draft.mitarbeiterart,
collective_agreement: draft.collectiveAgreement,
work_days: draft.workDays,
is_betriebsrat: draft.isBetriebsrat,
has_dienstwagen: draft.hasDienstwagen,
dienstwagen_art: draft.hasDienstwagen ? draft.dienstwagenArt : "",
is_laterale_fuehrung: draft.isLateraleFuehrung,
is_c_level: draft.isCLevel,
has_kuendigungsschutz: draft.hasKuendigungsschutz,
kuendigungsschutz_grund: draft.hasKuendigungsschutz ? draft.kuendigungsschutzGrund : "",
kuendigungsschutz_ab: draft.hasKuendigungsschutz ? draft.kuendigungsschutzAb : "",
kuendigungsschutz_bis: draft.hasKuendigungsschutz ? draft.kuendigungsschutzBis : "",
ist_beguenstigt_behindert: istBehindert,
behinderung_grad: istBehindert ? draft.behinderungGrad : "",
behinderung_ab: istBehindert ? draft.behinderungAb : "",
behinderung_bis: istBehindert ? draft.behinderungBis : "",
});
setSubmitting(false);
if (!result.success) {
showToast(result.error ?? "Fehler beim Speichern.", "error");
return;
}
router.refresh();
onClose();
showToast(`${fmtName(draft.firstName, draft.lastName)} wurde wiedereingestellt.`);
}
return (
<Modal
open={open}
onClose={onClose}
title="Wiedereintritt"
widthClassName="max-w-2xl"
footer={
<div className="flex w-full items-center justify-between">
<Button variant="ghost" onClick={onClose}>
Abbrechen
</Button>
<div className="flex gap-2">
{step > 0 && (
<Button variant="secondary" onClick={() => setStep((s) => s - 1)}>
Zurück
</Button>
)}
{step < letzterSchritt && (
<Button onClick={() => setStep((s) => s + 1)} disabled={!stepValid}>
Weiter
</Button>
)}
{step === letzterSchritt && (
<Button onClick={handleSubmit} pending={submitting}>
Wiedereinstellen
</Button>
)}
</div>
</div>
}
>
<p className="mb-4 rounded bg-surface px-3 py-2 text-sm text-ink-body">
Die Angaben stammen aus der bestehenden Akte und lassen sich hier ändern. Planstelle und Eintrittsdatum sind neu
zu wählen; Angehörige stehen bereits in der Akte.
</p>
<div className="mb-6 flex items-center justify-center gap-3">
{STEP_LABELS.map((label, i) => (
<button
key={label}
type="button"
disabled={i >= step}
aria-current={i === step ? "step" : undefined}
onClick={() => i < step && setStep(i)}
className={`flex items-center gap-2 rounded text-xs font-semibold focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500 disabled:cursor-default ${
i === step ? "text-brand-700" : i < step ? "text-ink-body" : "text-ink-muted"
}`}
>
<span
className={`flex h-6 w-6 items-center justify-center rounded-full ${i <= step ? "bg-brand-500 text-white" : "bg-surface text-ink-muted"}`}
>
{i + 1}
</span>
{label}
</button>
))}
</div>
{step === 0 && <StepPerson draft={draft} update={update} locations={locations} nummerGesperrt />}
{step === 1 && <StepPosition draft={draft} update={update} openPositions={openPositions} />}
{step === 2 && <StepVertrag draft={draft} update={update} />}
{step === 3 && <StepNotfallkontakt draft={draft} update={update} />}
{step === 4 && <StepSummary draft={draft} selectedPosition={selectedPosition} locations={locations} />}
</Modal>
);
}

View File

@@ -0,0 +1,113 @@
import { Plus, Trash2 } from "lucide-react";
import { Button } from "@/components/ui/Button";
import { SelectField, TextField } from "@/components/ui/Field";
import { fmtDate } from "@/lib/format";
import { formatSvnr, svnrErrorMessage, validateSvnr } from "@/lib/svnr";
import type { RelationshipType } from "@/lib/types";
import type { HireDraftAngehoerige, HireDraftData } from "./types";
const VERHAELTNIS: RelationshipType[] = ["Ehepartner:in", "Lebenspartner:in", "Kind", "Sonstige"];
// Angehörige im Assistenten, obwohl es die Person noch nicht gibt.
//
// Sie werden hier gesammelt und erst nach dem Anlegen angehängt — die
// Datenbankfunktion braucht eine Kennung, und die entsteht mit der
// Einstellung. Der Preis dafür steht in HireWizard: schlägt eine der
// Ergänzungen fehl, ist die Person trotzdem angelegt, und die Meldung sagt
// das dann auch.
//
// Freiwillig: die meisten Einstellungen kommen ohne aus, und wer später
// etwas nachträgt, findet denselben Dialog in der Personalakte.
export function StepAngehoerige({
draft,
update,
}: {
draft: HireDraftData;
update: (patch: Partial<HireDraftData>) => void;
}) {
const liste = draft.angehoerige;
function setze(index: number, patch: Partial<HireDraftAngehoerige>) {
update({ angehoerige: liste.map((a, i) => (i === index ? { ...a, ...patch } : a)) });
}
function hinzufuegen() {
update({
angehoerige: [...liste, { firstName: "", lastName: draft.lastName, relationship: "Kind", birthDate: "", svNummer: "" }],
});
}
return (
<div className="flex flex-col gap-4">
<p className="max-w-prose text-sm text-ink-muted">
Angehörige sind freiwillig und lassen sich jederzeit in der Personalakte nachtragen. Der Nachname ist mit dem
der einzustellenden Person vorbelegt — überschreibbar.
</p>
{liste.length === 0 ? (
<p className="text-sm text-ink-muted">Keine Angehörigen erfasst.</p>
) : (
<div className="flex flex-col gap-3">
{liste.map((a, i) => {
// Dieselbe Prüfung wie bei der Person selbst: Prüfziffer und
// Geburtsdatum müssen zusammenpassen. Hier schon, damit der
// Fehler nicht erst nach dem Anlegen auftaucht — dann existiert
// die Person bereits und die Angehörige fehlt.
const svFehler = a.svNummer.trim() ? validateSvnr(a.svNummer, a.birthDate || null) : null;
return (
<fieldset key={i} className="rounded-md border border-border p-3">
<legend className="flex items-center gap-2 px-1 text-xs font-semibold uppercase tracking-wide text-ink-muted">
{a.firstName || a.lastName ? `${a.firstName} ${a.lastName}`.trim() : `Angehörige:r ${i + 1}`}
{a.birthDate && <span className="font-normal normal-case">· {fmtDate(a.birthDate)}</span>}
</legend>
<div className="flex flex-col gap-3">
<div className="grid grid-cols-1 gap-3 sm:grid-cols-2">
<TextField label="Vorname" dense required value={a.firstName} onChange={(v) => setze(i, { firstName: v })} />
<TextField label="Nachname" dense required value={a.lastName} onChange={(v) => setze(i, { lastName: v })} />
</div>
<div className="grid grid-cols-1 gap-3 sm:grid-cols-2">
<SelectField
label="Verhältnis"
dense
required
value={a.relationship}
onChange={(v) => setze(i, { relationship: v as RelationshipType })}
options={VERHAELTNIS.map((r) => ({ value: r, label: r }))}
/>
<TextField label="Geburtsdatum" dense required type="date" value={a.birthDate} onChange={(v) => setze(i, { birthDate: v })} />
</div>
<TextField
label="SV-Nummer"
dense
value={a.svNummer}
onChange={(v) => setze(i, { svNummer: v })}
error={svFehler ? svnrErrorMessage(svFehler) : undefined}
hint={!svFehler && a.svNummer.trim() ? formatSvnr(a.svNummer) : undefined}
/>
</div>
<div className="mt-2 flex justify-end">
<Button
variant="ghost"
size="sm"
onClick={() => update({ angehoerige: liste.filter((_, j) => j !== i) })}
className="!px-1 text-danger-text hover:!bg-transparent hover:underline"
>
<Trash2 className="h-3.5 w-3.5" /> Entfernen
</Button>
</div>
</fieldset>
);
})}
</div>
)}
<div>
<Button variant="secondary" size="sm" onClick={hinzufuegen}>
<Plus className="h-4 w-4" /> Angehörige:n hinzufügen
</Button>
</div>
</div>
);
}

View File

@@ -0,0 +1,60 @@
import { SelectField, TextField } from "@/components/ui/Field";
import { EMERGENCY_RELATIONS } from "@/lib/types";
import type { HireDraftData } from "./types";
// Eigener Schritt, kurz vor der Zusammenfassung.
//
// Zuerst stand das zwischen den Stammdaten — dort ging es unter, obwohl es
// die einzige Angabe im ganzen Assistenten ist, die eine dritte Person
// betrifft und im Ernstfall gebraucht wird.
//
// Die Angabe bleibt freiwillig. Wer sie macht, braucht Name und Nummer
// zusammen; das prüft der Assistent, bevor er weiterlässt, und die Datenbank
// noch einmal (chk_emergency_contact).
export function StepNotfallkontakt({
draft,
update,
}: {
draft: HireDraftData;
update: (patch: Partial<HireDraftData>) => void;
}) {
const angefangen = Boolean(draft.emergencyContactName.trim() || draft.emergencyContactPhone.trim());
const unvollstaendig = angefangen && !(draft.emergencyContactName.trim() && draft.emergencyContactPhone.trim());
return (
<div className="flex flex-col gap-4">
<p className="max-w-prose text-sm text-ink-muted">
Wen sollen wir verständigen, wenn etwas passiert? Die Angabe ist freiwillig — Name und Telefonnummer gehören
aber zusammen, eines allein hilft im Ernstfall nicht.
</p>
<div className="grid grid-cols-1 gap-3 sm:grid-cols-2">
<TextField
label="Name"
value={draft.emergencyContactName}
onChange={(emergencyContactName) => update({ emergencyContactName })}
/>
<TextField
label="Telefon"
type="tel"
value={draft.emergencyContactPhone}
onChange={(emergencyContactPhone) => update({ emergencyContactPhone })}
/>
</div>
<SelectField
label="Verhältnis"
value={draft.emergencyContactRelation}
onChange={(emergencyContactRelation) => update({ emergencyContactRelation })}
placeholder="Bitte wählen…"
options={EMERGENCY_RELATIONS.map((r) => ({ value: r, label: r }))}
/>
{unvollstaendig && (
<p role="alert" className="rounded-md border border-danger-text/20 bg-danger-bg px-3 py-2 text-sm text-danger-text">
Name und Telefonnummer werden beide gebraucht — oder beide leer lassen.
</p>
)}
</div>
);
}

View File

@@ -1,17 +1,44 @@
import { SvNummerField } from "@/components/employees/SvNummerField";
import { TitleFields } from "@/components/employees/TitleFields";
import { SelectField, TextField } from "@/components/ui/Field";
import { PersonalnummerField } from "./PersonalnummerField";
import type { HireDraftData } from "./types";
type StepPersonProps = {
draft: HireDraftData;
update: (patch: Partial<HireDraftData>) => void;
locations: { id: string; name: string; country: string }[];
/** Meldet die geprüfte Personalnummer und ihr Ergebnis — steuert „Weiter". */
onNummerBefund?: (befund: { nummer: number; vergeben: boolean }) => void;
/**
* Beim Wiedereintritt: die Nummer steht fest und wird nur gezeigt.
*
* Zwei Gründe. Es ist dieselbe Person und sie behält ihre Nummer — und die
* Prüfung auf Dubletten fände hier zwangsläufig einen Treffer, nämlich sie
* selbst, und sperrte das Formular mit einer Meldung, die stimmt und
* trotzdem in die Irre führt.
*/
nummerGesperrt?: boolean;
};
export function StepPerson({ draft, update, locations }: StepPersonProps) {
export function StepPerson({ draft, update, locations, onNummerBefund, nummerGesperrt }: StepPersonProps) {
return (
<div className="flex flex-col gap-4">
{nummerGesperrt ? (
<TextField
label="Personalnummer"
value={draft.personnelNumber}
onChange={() => {}}
disabled
hint="Bleibt bei einem Wiedereintritt dieselbe."
/>
) : (
<PersonalnummerField
wert={draft.personnelNumber}
onChange={(personnelNumber) => update({ personnelNumber })}
onBefund={onNummerBefund ?? (() => {})}
/>
)}
<div className="grid grid-cols-1 gap-3 sm:grid-cols-2">
<TextField label="Vorname" required value={draft.firstName} onChange={(firstName) => update({ firstName })} />
<TextField label="Nachname" required value={draft.lastName} onChange={(lastName) => update({ lastName })} />
@@ -37,8 +64,23 @@ export function StepPerson({ draft, update, locations }: StepPersonProps) {
birthDate={draft.birthDate || null}
/>
<div className="grid grid-cols-1 gap-3 sm:grid-cols-2">
<TextField label="E-Mail (privat)" type="email" value={draft.email} onChange={(email) => update({ email })} />
<TextField label="Telefon" type="tel" value={draft.phone} onChange={(phone) => update({ phone })} />
{/* Die private Adresse, nicht die Firmenadresse — die entsteht erst
mit dem Eintritt. Freiwillig: wer keine hat oder keine angeben
will, soll nicht gezwungen sein, eine zu erfinden. */}
<TextField label="Private E-Mail" type="email" value={draft.email} onChange={(email) => update({ email })} />
<TextField
label="Firmen-E-Mail"
type="email"
value={draft.companyEmail}
onChange={(companyEmail) => update({ companyEmail })}
/>
<TextField
label="Cornerstone-ID"
value={draft.cornerstoneId}
onChange={(cornerstoneId) => update({ cornerstoneId })}
hint="Freiwillig. Füllt im Cornerstone-Export „User ID“ und „Username“."
/>
<TextField label="Private Telefonnummer" type="tel" value={draft.phone} onChange={(phone) => update({ phone })} />
</div>
<SelectField
label="Standort"

View File

@@ -1,16 +1,9 @@
import { dienstwagenLabel } from "@/lib/dienstwagen";
import { fmtDate, fmtFullName } from "@/lib/format";
import { hayGradeLabel } from "@/lib/hay-grade";
import type { OpenPositionResolved } from "@/lib/positions";
import type { HireDraftData } from "./types";
const PAYGRADE_LABELS: Record<string, string> = {
A: "A – Einstieg",
B: "B – Qualifiziert",
C: "C – Erfahren",
D: "D – Spezialist:in",
E: "E – Teamleitung",
F: "F – Bereichsleitung / GF",
};
type StepSummaryProps = {
draft: HireDraftData;
selectedPosition: OpenPositionResolved | null;
@@ -21,17 +14,25 @@ export function StepSummary({ draft, selectedPosition, locations }: StepSummaryP
const location = locations.find((l) => l.id === draft.locationId);
const flags = [
draft.isBetriebsrat && "Betriebsrat",
draft.hasDienstwagen && "Dienstwagen",
draft.hasDienstwagen && `Dienstwagen (${dienstwagenLabel(draft.dienstwagenArt)})`,
draft.isLateraleFuehrung && "Laterale Führung",
draft.isCLevel && "C-Level",
draft.hasKuendigungsschutz &&
`Besonderer Kündigungsschutz${draft.kuendigungsschutzBis ? ` bis ${fmtDate(draft.kuendigungsschutzBis)}` : ""}`,
].filter(Boolean);
const notfall = [draft.emergencyContactName, draft.emergencyContactRelation && `(${draft.emergencyContactRelation})`, draft.emergencyContactPhone]
.filter(Boolean)
.join(" ");
const rows: [string, string][] = [
["Personalnummer", draft.personnelNumber || "–"],
["Name", fmtFullName(draft.firstName, draft.lastName, draft.titlePrefix, draft.titleSuffix)],
["Geschlecht", draft.gender === "m" ? "männlich" : "weiblich"],
["Geburtsdatum", fmtDate(draft.birthDate)],
["SV-Nummer", draft.svNummer || "–"],
["E-Mail (privat)", draft.email || "–"],
["Telefon", draft.phone || "–"],
["Notfallkontakt", notfall || "–"],
["Standort", location ? `${location.name} (${location.country})` : "–"],
["Position", selectedPosition ? `${selectedPosition.title} (${selectedPosition.position_number})` : "–"],
["Organisationseinheit", selectedPosition?.orgLabel ?? "–"],
@@ -40,8 +41,8 @@ export function StepSummary({ draft, selectedPosition, locations }: StepSummaryP
["Eintrittsdatum", fmtDate(draft.entryDate)],
["Vertragsart", draft.contractType === "befristet" ? `befristet bis ${fmtDate(draft.contractEndDate)}` : "unbefristet"],
["Beschäftigungsausmaß", `${draft.employmentType} (${draft.weeklyHours} h)`],
["Paygrade", PAYGRADE_LABELS[draft.paygrade]],
["Angestellte:r / Arbeiter:in", draft.workerType],
["Hay-Grade", hayGradeLabel(draft.paygrade)],
["Beschäftigtengruppe", draft.workerType],
["Kollektivvertrag", draft.collectiveAgreement],
["Arbeitstage", draft.workDays.join(", ") || "–"],
["Merkmale", flags.length > 0 ? flags.join(", ") : "–"],
@@ -57,9 +58,6 @@ export function StepSummary({ draft, selectedPosition, locations }: StepSummaryP
</div>
))}
</dl>
<p className="rounded bg-info-bg px-3 py-2 text-sm text-info-text">
Personalnummer und Firmen-E-Mail-Adresse werden automatisch vergeben.
</p>
</div>
);
}

View File

@@ -1,17 +1,9 @@
import { RoleEmploymentFields } from "@/components/employees/RoleEmploymentFields";
import { SelectField, TextField } from "@/components/ui/Field";
import type { PaygradeType } from "@/lib/supabase/types";
import { HAY_GRADES } from "@/lib/hay-grade";
import type { PaygradeType } from "@/lib/types";
import type { HireDraftData } from "./types";
const PAYGRADES: { value: PaygradeType; label: string; description: string }[] = [
{ value: "A", label: "A – Einstieg", description: "Berufseinsteiger:innen ohne einschlägige Erfahrung" },
{ value: "B", label: "B – Qualifiziert", description: "Fachkräfte mit abgeschlossener Ausbildung" },
{ value: "C", label: "C – Erfahren", description: "Mehrjährige einschlägige Berufserfahrung" },
{ value: "D", label: "D – Spezialist:in", description: "Vertiefte Fachexpertise" },
{ value: "E", label: "E – Teamleitung", description: "Fachliche und disziplinäre Führung eines Teams" },
{ value: "F", label: "F – Bereichsleitung / GF", description: "Führung eines Bereichs bzw. Geschäftsführung" },
];
export function StepVertrag({ draft, update }: { draft: HireDraftData; update: (patch: Partial<HireDraftData>) => void }) {
function handleEmploymentTypeChange(value: HireDraftData["employmentType"]) {
update({
@@ -63,12 +55,11 @@ export function StepVertrag({ draft, update }: { draft: HireDraftData; update: (
/>
</div>
<SelectField
label="Paygrade"
label="Hay-Grade"
required
value={draft.paygrade}
onChange={(v) => update({ paygrade: v as PaygradeType })}
options={PAYGRADES}
hint={PAYGRADES.find((p) => p.value === draft.paygrade)?.description}
options={HAY_GRADES}
/>
<p className="text-xs text-ink-muted">Es gilt eine Probezeit von 1 Monat gemäß Kollektivvertrag.</p>

View File

@@ -1,9 +1,32 @@
import type { CollectiveAgreement, ContractType, EmploymentType, GenderType, PaygradeType, Weekday, WorkerType } from "@/lib/supabase/types";
import { HAY_GRADE_STANDARD } from "@/lib/hay-grade";
import { MITARBEITERART_STANDARD } from "@/lib/mitarbeiterart";
import type { CollectiveAgreement, ContractType, DienstwagenArt, EmploymentType, GenderType, Mitarbeiterart, PaygradeType, RelationshipType, Weekday, WorkerType } from "@/lib/types";
// The spec's hire wizard field list (§4.4) omits Geschlecht and Standort even
// though both are NOT NULL on employees — added here (defaults keep them
// effectively "free" for the user, same treatment as the karenz-start gap).
/**
* Angehörige:r, wie sie im Assistenten gesammelt wird.
*
* Eigener Typ statt der Zeile aus der Datenbank: es gibt weder eine Kennung
* noch eine Person, an der sie hängt — beides entsteht erst mit dem Anlegen.
*/
export type HireDraftAngehoerige = {
firstName: string;
lastName: string;
relationship: RelationshipType;
birthDate: string;
svNummer: string;
};
export type HireDraftData = {
/**
* Eingabe, nicht Vergabe.
*
* Muss mit Loga und Interflex übereinstimmen — als Zeichenkette geführt,
* weil ein leeres Zahlenfeld sonst als 0 im Entwurf landet.
*/
personnelNumber: string;
firstName: string;
lastName: string;
titlePrefix: string[];
@@ -12,6 +35,9 @@ export type HireDraftData = {
birthDate: string;
svNummer: string;
email: string;
companyEmail: string;
/** Kennung im Lernsystem Cornerstone. Freiwillig. */
cornerstoneId: string;
phone: string;
locationId: string;
positionId: string;
@@ -27,11 +53,31 @@ export type HireDraftData = {
workDays: Weekday[];
isBetriebsrat: boolean;
hasDienstwagen: boolean;
/** Nur ausgewertet, wenn hasDienstwagen gesetzt ist — so will es der CHECK. */
dienstwagenArt: DienstwagenArt;
emergencyContactName: string;
emergencyContactPhone: string;
emergencyContactRelation: string;
angehoerige: HireDraftAngehoerige[];
isLateraleFuehrung: boolean;
isCLevel: boolean;
/** Form der Beschäftigung — zweite Achse neben der Beschäftigtengruppe. */
mitarbeiterart: Mitarbeiterart;
hasKuendigungsschutz: boolean;
/** Freiwillig — leer heisst „bis auf Weiteres". */
kuendigungsschutzBis: string;
/** Personenkreis nach dem besonderen Kündigungsschutz; leer heisst „nicht erfasst". */
kuendigungsschutzGrund: string;
kuendigungsschutzAb: string;
istBeguenstigtBehindert: boolean;
/** Grad in Prozent als Text — ein leeres Zahlenfeld wäre sonst 0. */
behinderungGrad: string;
behinderungAb: string;
behinderungBis: string;
};
export const EMPTY_HIRE_DRAFT: HireDraftData = {
personnelNumber: "",
firstName: "",
lastName: "",
titlePrefix: [],
@@ -40,6 +86,8 @@ export const EMPTY_HIRE_DRAFT: HireDraftData = {
birthDate: "",
svNummer: "",
email: "",
companyEmail: "",
cornerstoneId: "",
phone: "",
locationId: "",
positionId: "",
@@ -49,12 +97,26 @@ export const EMPTY_HIRE_DRAFT: HireDraftData = {
contractEndDate: "",
employmentType: "Vollzeit",
weeklyHours: "38.5",
paygrade: "B",
paygrade: HAY_GRADE_STANDARD,
workerType: "Angestellte:r",
collectiveAgreement: "Handel",
workDays: ["Mo", "Di", "Mi", "Do", "Fr"],
isBetriebsrat: false,
hasDienstwagen: false,
dienstwagenArt: "Verbrenner",
emergencyContactName: "",
emergencyContactPhone: "",
emergencyContactRelation: "",
angehoerige: [],
isLateraleFuehrung: false,
isCLevel: false,
mitarbeiterart: MITARBEITERART_STANDARD,
hasKuendigungsschutz: false,
kuendigungsschutzBis: "",
kuendigungsschutzGrund: "",
kuendigungsschutzAb: "",
istBeguenstigtBehindert: false,
behinderungGrad: "",
behinderungAb: "",
behinderungBis: "",
};

View File

@@ -0,0 +1,210 @@
"use client";
import { useRef, useState } from "react";
import { Button } from "@/components/ui/Button";
import { CARD_CLASS } from "@/components/ui/Card";
// Der Ablauf hat bewusst zwei Schritte: prüfen, dann übernehmen.
//
// Ein Import ist nicht rückgängig zu machen. Wer 800 Zeilen schickt, soll
// vorher sehen, was entstehen würde — und bei einem Fehler die Zeilennummer
// lesen, nicht „Import fehlgeschlagen".
type Befund = { blatt: string; zeile: number | null; spalte: string | null; wert?: string; meldung: string };
type Antwort = {
ok: boolean;
geprueft: boolean;
blaetter: string[];
fehler: Befund[];
hinweise: Befund[];
anzahl: Record<string, number>;
bericht?: Record<string, number>;
meldung?: string;
};
/** Mehr als das zeigt niemand durch; der Rest steht in der Anzahl. */
const MAX_ANZEIGE = 200;
export function ImportWorkbench() {
const [dateien, setDateien] = useState<File[]>([]);
const [antwort, setAntwort] = useState<Antwort | null>(null);
const [laeuft, setLaeuft] = useState<"pruefen" | "uebernehmen" | null>(null);
const [fehlschlag, setFehlschlag] = useState<string | null>(null);
const eingabe = useRef<HTMLInputElement>(null);
async function senden(nurPruefen: boolean) {
if (dateien.length === 0) return;
setLaeuft(nurPruefen ? "pruefen" : "uebernehmen");
setFehlschlag(null);
try {
const daten = new FormData();
for (const d of dateien) daten.append("datei", d);
if (nurPruefen) daten.append("pruefen", "1");
const antwort = await fetch("/api/import", { method: "POST", body: daten });
const inhalt = (await antwort.json()) as Antwort;
setAntwort(inhalt);
} catch {
setFehlschlag("Die Datei konnte nicht übertragen werden. Bitte erneut versuchen.");
} finally {
setLaeuft(null);
}
}
function neueAuswahl(liste: FileList | null) {
setDateien(liste ? Array.from(liste) : []);
// Ein alter Bericht zu einer neuen Datei ist schlimmer als keiner.
setAntwort(null);
setFehlschlag(null);
}
const uebernommen = antwort?.bericht !== undefined;
const bereit = antwort?.ok === true && antwort.geprueft && !uebernommen;
return (
<div className="flex flex-col gap-4">
<section className={`${CARD_CLASS} p-5`}>
<div className="flex flex-wrap items-start justify-between gap-4">
<div>
<h2 className="text-sm font-bold text-ink">Datei wählen</h2>
<p className="mt-1 max-w-prose text-sm text-ink-muted">
Eine Excel-Mappe mit den Blättern <strong>Standorte</strong>, <strong>Organisation</strong>,{" "}
<strong>Jobkatalog</strong>, <strong>Planstellen</strong>, <strong>Personen</strong>,{" "}
<strong>Historie</strong> und <strong>Angehörige</strong> — oder je Blatt eine CSV-Datei, deren Name dem
Blatt entspricht. Nicht jedes Blatt muss dabei sein.
</p>
</div>
<a
href="/api/import/template"
className="shrink-0 rounded-md border border-border px-3 py-2 text-sm font-semibold text-ink hover:bg-brand-50
focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500"
>
Vorlage herunterladen
</a>
</div>
<div className="mt-4 flex flex-wrap items-center gap-3">
<input
ref={eingabe}
type="file"
multiple
accept=".xlsx,.xlsm,.csv"
onChange={(e) => neueAuswahl(e.target.files)}
className="block w-full max-w-md text-sm text-ink-muted file:mr-3 file:rounded-md file:border file:border-border
file:bg-surface file:px-3 file:py-2 file:text-sm file:font-semibold file:text-ink hover:file:bg-brand-50"
/>
<Button onClick={() => senden(true)} disabled={dateien.length === 0 || laeuft !== null}>
{laeuft === "pruefen" ? "Wird geprüft…" : "Prüfen"}
</Button>
</div>
{dateien.length > 0 && (
<p className="mt-2 text-xs text-ink-muted">
{dateien.length === 1 ? dateien[0].name : `${dateien.length} Dateien`} ausgewählt
</p>
)}
</section>
{fehlschlag && (
<p role="alert" className="rounded-md border border-danger-text/20 bg-danger-bg px-4 py-3 text-sm text-danger-text">
{fehlschlag}
</p>
)}
{antwort?.meldung && (
<p role="alert" className="rounded-md border border-danger-text/20 bg-danger-bg px-4 py-3 text-sm text-danger-text">
{antwort.meldung}
</p>
)}
{antwort && !antwort.meldung && (
<section className={`${CARD_CLASS} p-5`}>
<h2 className="text-sm font-bold text-ink">{uebernommen ? "Übernommen" : "Ergebnis der Prüfung"}</h2>
<table className="mt-3 w-full max-w-md text-sm">
<tbody>
{Object.entries(uebernommen ? antwort.bericht! : antwort.anzahl)
.filter(([, n]) => n > 0)
.map(([blatt, n]) => (
<tr key={blatt} className="border-b border-border-subtle last:border-0">
<td className="py-1.5 text-ink-body">{blatt}</td>
<td className="py-1.5 text-right font-semibold tabular-nums text-ink">{n}</td>
</tr>
))}
</tbody>
</table>
{uebernommen ? (
<p className="mt-4 text-sm text-ink-muted">
Die Daten stehen jetzt in der Anwendung. Der Vorgang ist im Audit-Log vermerkt.
</p>
) : antwort.ok ? (
<>
<p className="mt-4 text-sm text-ink-body">
Keine Beanstandung. Beim Übernehmen entsteht genau das oben Gezeigte — alles in einem Zug oder gar
nichts.
</p>
<div className="mt-3">
<Button onClick={() => senden(false)} disabled={laeuft !== null || !bereit}>
{laeuft === "uebernehmen" ? "Wird übernommen…" : "Übernehmen"}
</Button>
</div>
</>
) : (
<p className="mt-4 text-sm font-semibold text-danger-text">
{antwort.fehler.length} Beanstandung{antwort.fehler.length === 1 ? "" : "en"} — es wurde nichts
geschrieben.
</p>
)}
</section>
)}
{antwort && antwort.fehler.length > 0 && (
<BefundListe titel="Zu beheben" befunde={antwort.fehler} art="fehler" />
)}
{antwort && antwort.hinweise.length > 0 && (
<BefundListe titel="Hinweise" befunde={antwort.hinweise} art="hinweis" />
)}
</div>
);
}
function BefundListe({ titel, befunde, art }: { titel: string; befunde: Befund[]; art: "fehler" | "hinweis" }) {
const sichtbar = befunde.slice(0, MAX_ANZEIGE);
return (
<section className={`overflow-x-auto overflow-y-hidden ${CARD_CLASS}`}>
<h2 className="px-5 pt-5 text-sm font-bold text-ink">
{titel} <span className="font-normal text-ink-muted">({befunde.length})</span>
</h2>
<table className="mt-3 w-full min-w-[640px] text-sm">
<thead>
<tr className="border-y border-border bg-surface text-left text-[11px] font-bold uppercase tracking-wider text-ink-muted">
<th className="px-5 py-2">Blatt</th>
<th className="px-3 py-2">Zeile</th>
<th className="px-3 py-2">Spalte</th>
<th className="px-3 py-2">Wert</th>
<th className="px-5 py-2">Was zu tun ist</th>
</tr>
</thead>
<tbody>
{sichtbar.map((b, i) => (
<tr key={i} className="border-b border-border-subtle last:border-0">
<td className="whitespace-nowrap px-5 py-2 text-ink-body">{b.blatt}</td>
<td className="px-3 py-2 tabular-nums text-ink-muted">{b.zeile ?? "–"}</td>
<td className="px-3 py-2 text-ink-body">{b.spalte ?? "–"}</td>
<td className="max-w-[16rem] truncate px-3 py-2 text-ink-muted" title={b.wert}>
{b.wert ?? ""}
</td>
<td className={`px-5 py-2 ${art === "fehler" ? "text-danger-text" : "text-ink-muted"}`}>{b.meldung}</td>
</tr>
))}
</tbody>
</table>
{befunde.length > sichtbar.length && (
<p className="px-5 py-3 text-xs text-ink-muted">
Weitere {befunde.length - sichtbar.length} nicht angezeigt. Oft hängen viele Meldungen an einer Ursache —
nach der Korrektur erneut prüfen.
</p>
)}
</section>
);
}

View File

@@ -2,8 +2,9 @@
import { CalendarClock } from "lucide-react";
import { usePathname, useRouter, useSearchParams } from "next/navigation";
import { useState } from "react";
import { Button } from "@/components/ui/Button";
import { FILTER_SELECT_CLASS } from "@/components/ui/Field";
import { FILTER_SELECT_CLASS, istMeldbaresDatum } from "@/components/ui/Field";
import { fmtDate } from "@/lib/format";
type AsOfPickerProps = {
@@ -27,6 +28,14 @@ export function AsOfPicker({ asOf, today, projectedCount, historyStartsAt }: AsO
router.push(sp.size > 0 ? `${pathname}?${sp}` : pathname, { scroll: false });
}
// Angeglichen während des Renderns, nicht in einem Effekt — siehe DateField.
const [entwurf, setEntwurf] = useState(asOf);
const [zuletzt, setZuletzt] = useState(asOf);
if (asOf !== zuletzt) {
setZuletzt(asOf);
setEntwurf(asOf);
}
const isToday = asOf === today;
const isFuture = asOf > today;
// Assignments only started being recorded when the history table was
@@ -41,11 +50,23 @@ export function AsOfPicker({ asOf, today, projectedCount, historyStartsAt }: AsO
<CalendarClock className="h-4 w-4 text-ink-muted" />
Stichtag
</label>
{/* Der Tippstand bleibt hier, gemeldet wird nur ein vollständiges
Datum: jede Änderung ist eine Navigation, und beim Tippen der
Jahreszahl entstehen unterwegs 0002, 0020 und 0202 — jede davon
lud die Seite neu und setzte das Feld mitten im Tippen zurück.
Dieselbe Regel wie in DateField, dort steht auch der lange Grund. */}
<input
id="orgchart-asof"
type="date"
value={asOf}
onChange={(e) => setAsOf(e.target.value || undefined)}
value={entwurf}
onChange={(e) => {
const wert = e.target.value;
setEntwurf(wert);
if (istMeldbaresDatum(wert) && wert !== asOf) setAsOf(wert || undefined);
}}
onBlur={() => {
if (entwurf !== asOf && istMeldbaresDatum(entwurf)) setAsOf(entwurf || undefined);
}}
className={FILTER_SELECT_CLASS}
/>
{!isToday && (

View File

@@ -0,0 +1,126 @@
"use client";
import { useRouter } from "next/navigation";
import { useState } from "react";
import { createOrgUnit } from "@/actions/org";
import { Button } from "@/components/ui/Button";
import { SelectField, TextField } from "@/components/ui/Field";
import { Modal } from "@/components/ui/Modal";
import { useToast } from "@/components/ui/Toast";
import { todayIso } from "@/lib/format";
import { naechsteOrgnummer } from "@/lib/org-nummer";
import type { OrgUnitNode } from "./types";
type Art = "Bereich" | "Abteilung" | "Team";
// „Gesellschaft“ fehlt in der Auswahl mit Absicht: es gibt genau eine, sie ist
// die Wurzel, und unter einer anderen Einheit wäre sie ein Etikett, das seiner
// Stelle im Baum widerspricht. Die Datenbankfunktion weist es ohnehin ab — die
// fehlende Zeile erspart den Weg dorthin.
const ARTEN: { value: Art; label: string }[] = [
{ value: "Bereich", label: "Bereich" },
{ value: "Abteilung", label: "Abteilung" },
{ value: "Team", label: "Team" },
];
/**
* Die Art, die unter einer Einheit am wahrscheinlichsten ist: eine Stufe
* feiner als die darüber. Nur eine Vorbelegung — die Tiefe des Baums ist frei,
* und eine Abteilung unter einer Abteilung ist erlaubt.
*/
function vorschlagArt(eltern: OrgUnitNode["unit_type"]): Art {
if (eltern === "Gesellschaft") return "Bereich";
if (eltern === "Bereich") return "Abteilung";
return "Team";
}
export function CreateOrgUnitModal({
parent,
units,
onClose,
}: {
parent: OrgUnitNode;
units: OrgUnitNode[];
onClose: () => void;
}) {
const { showToast } = useToast();
const router = useRouter();
const [orgNumber, setOrgNumber] = useState(() => naechsteOrgnummer(units.map((u) => u.org_number)) ?? "");
const [name, setName] = useState("");
const [art, setArt] = useState<Art>(() => vorschlagArt(parent.unit_type));
// **Nicht** der Stichtag der Ansicht. Wer sich das Organigramm zum letzten
// Jahresende ansieht und hier auf Plus drückt, will in aller Regel eine
// Einheit von heute anlegen und keine rückdatierte. Ein stillschweigend
// übernommenes Datum aus der Ansicht wäre die Art von Vorbelegung, die
// niemand liest und die hinterher niemand erklären kann.
const [validFrom, setValidFrom] = useState(todayIso);
const [leitung, setLeitung] = useState("");
const [pending, setPending] = useState(false);
async function handleSubmit() {
if (!orgNumber.trim() || !name.trim() || !validFrom) {
showToast("Orgnummer, Bezeichnung und Gültigkeitsbeginn sind Pflicht.", "error");
return;
}
setPending(true);
const result = await createOrgUnit({
parent_id: parent.id,
org_number: orgNumber.trim(),
name: name.trim(),
unit_type: art,
valid_from: validFrom,
leitung_taetigkeit: leitung.trim() || undefined,
});
setPending(false);
if (result.success) {
showToast(leitung.trim() ? "Einheit samt Leitungsplanstelle angelegt." : "Einheit angelegt.");
router.refresh();
onClose();
} else {
showToast(result.error ?? "Fehler beim Anlegen.", "error");
}
}
return (
<Modal
open
onClose={onClose}
title="Einheit anlegen"
footer={
<>
<Button variant="ghost" onClick={onClose}>
Abbrechen
</Button>
<Button onClick={handleSubmit} pending={pending}>
Anlegen
</Button>
</>
}
>
<div className="flex flex-col gap-4">
<p className="rounded-md bg-surface px-3 py-2 text-xs leading-relaxed text-ink-muted">
Unter <span className="font-semibold text-ink-body">{parent.org_number} · {parent.name}</span>.
Bestehende Einheiten lassen sich nicht hierher verschieben — die neue entsteht leer.
</p>
<TextField
label="Orgnummer"
required
value={orgNumber}
onChange={setOrgNumber}
hint="Vorgeschlagen wird die nächste freie Nummer der bestehenden Reihe. Sie muss zum führenden System passen."
/>
<TextField label="Bezeichnung" required value={name} onChange={setName} />
<SelectField label="Art" required value={art} onChange={(v) => setArt(v as Art)} options={ARTEN} />
<TextField label="Gültig ab" required type="date" value={validFrom} onChange={setValidFrom} />
<TextField
label="Leitungsplanstelle (optional)"
value={leitung}
onChange={setLeitung}
hint="Tätigkeit der Leitung, z. B. „Abteilungsleitung Einkauf“. Leer lassen, dann entsteht die Einheit ohne Leitung und ist im Organigramm als vakant zu sehen."
/>
</div>
</Modal>
);
}

View File

@@ -9,6 +9,7 @@ import { SearchInput } from "@/components/ui/SearchInput";
import { SegmentedControl } from "@/components/ui/SegmentedControl";
import { LazyGraphOrgChart } from "./LazyGraphOrgChart";
import type { ChartNode, OrgEmployee } from "./types";
import { fmtName } from "@/lib/format";
type ViewMode = "list" | "graph";
@@ -53,7 +54,7 @@ export function EmployeeTree({ employees, focusId = null }: { employees: OrgEmpl
// Both badges name a person by id, so the lookup is shared rather than
// rebuilt per node.
const nameById = useMemo(() => new Map(employees.map((e) => [e.id, `${e.first_name} ${e.last_name}`])), [employees]);
const nameById = useMemo(() => new Map(employees.map((e) => [e.id, fmtName(e.first_name, e.last_name)])), [employees]);
const nameOf = useCallback((id: string | null) => (id ? nameById.get(id) : undefined), [nameById]);
const matchIds = useMemo(() => {
@@ -64,8 +65,17 @@ export function EmployeeTree({ employees, focusId = null }: { employees: OrgEmpl
const q = query.trim().toLowerCase();
const matches = new Set<string>();
for (const e of employees) {
// Beide Reihenfolgen: angezeigt wird „Winkler, Hannah", im Kopf hat man
// aber je nach Anlass das eine oder das andere zuerst. Wer abtippt, was
// er sieht, soll ebenso fündig werden wie jemand, der „hannah winkler"
// eingibt.
const vorNach = `${e.first_name} ${e.last_name}`.toLowerCase();
const nachVor = fmtName(e.first_name, e.last_name).toLowerCase();
if (
`${e.first_name} ${e.last_name}`.toLowerCase().includes(q) ||
vorNach.includes(q) ||
nachVor.includes(q) ||
// Ohne den Beistrich, falls jemand ihn beim Abtippen weglässt.
nachVor.replace(",", "").includes(q) ||
e.job_title.toLowerCase().includes(q) ||
String(e.personnel_number).includes(q)
) {
@@ -118,7 +128,7 @@ export function EmployeeTree({ employees, focusId = null }: { employees: OrgEmpl
return {
id: e.id,
kind: "person",
label: `${e.first_name} ${e.last_name}`,
label: fmtName(e.first_name, e.last_name),
sublabel: e.job_title,
href: `/employees/${e.id}`,
avatar: { firstName: e.first_name, lastName: e.last_name },
@@ -146,7 +156,7 @@ export function EmployeeTree({ employees, focusId = null }: { employees: OrgEmpl
<div key={e.id}>
<div
ref={e.id === focusId ? focusRef : undefined}
className={`flex items-center gap-2 rounded px-2 py-1.5 hover:bg-surface ${isMatch ? "bg-brand-100" : ""}`}
className={`flex items-center gap-2 rounded px-2 py-1.5 hover:bg-surface ${isMatch ? "bg-accent-200" : ""}`}
style={{ paddingLeft: depth * 24 + 8 }}
>
{hasChildren ? (
@@ -159,7 +169,7 @@ export function EmployeeTree({ employees, focusId = null }: { employees: OrgEmpl
<Avatar firstName={e.first_name} lastName={e.last_name} size="sm" />
<Link href={`/employees/${e.id}`} className="min-w-0 flex-1 hover:underline">
<span className="text-sm font-semibold text-ink">
{e.first_name} {e.last_name}
{fmtName(e.first_name, e.last_name)}
</span>
<span className="ml-2 text-xs text-ink-muted">{e.job_title}</span>
</Link>

View File

@@ -23,11 +23,15 @@ import type { ChartNode, ChartNodeKind } from "./types";
// object as a change and remounts every custom node otherwise.
const NODE_TYPES = { orgNode: OrgChartNode };
// React Flow nimmt echte Farbwerte, keine Klassen — deshalb stehen die
// Token hier als Literal. Sie folgen KIND_ACCENT in OrgChartNode; laeuft das
// eine dem anderen davon, zeigt die Uebersichtskarte andere Farben als die
// Karten, ueber die sie liegt.
const MINIMAP_COLORS: Record<ChartNodeKind, string> = {
person: "#d6046e",
role: "#5c2e91",
group: "#c9b3c0",
vacancy: "#f6cfe2",
person: "#164194", // brand-500, Manner Blau
role: "#54277f", // purple-text
group: "#756c6e", // ink-muted
vacancy: "#f69686", // accent-500, Manner Rosa
};
export type GraphOrgChartProps = {
@@ -35,6 +39,10 @@ export type GraphOrgChartProps = {
isExpanded: (id: string) => boolean;
onToggle: (id: string) => void;
matchedIds?: Set<string> | null;
/** Nur die Struktursicht reicht sie herein; in der Mitarbeitersicht gibt es keine Einheiten. */
onAddUnit?: (unitId: string) => void;
onDeleteUnit?: (unitId: string) => void;
onSelectUnit?: (unitId: string) => void;
};
export function GraphOrgChart(props: GraphOrgChartProps) {
@@ -45,7 +53,15 @@ export function GraphOrgChart(props: GraphOrgChartProps) {
);
}
function GraphOrgChartInner({ tree, isExpanded, onToggle, matchedIds }: GraphOrgChartProps) {
function GraphOrgChartInner({
tree,
isExpanded,
onToggle,
matchedIds,
onAddUnit,
onDeleteUnit,
onSelectUnit,
}: GraphOrgChartProps) {
const { visibleNodes, visibleEdges } = useMemo(() => collectVisible(tree, isExpanded), [tree, isExpanded]);
const { rfNodes, rfEdges } = useMemo(() => {
@@ -61,6 +77,9 @@ function GraphOrgChartInner({ tree, isExpanded, onToggle, matchedIds }: GraphOrg
hasChildren: n.children.length > 0,
childCount: n.children.length,
onToggle,
onAddUnit,
onDeleteUnit,
onSelectUnit,
},
}));
const rfEdges: Edge[] = visibleEdges.map((e) => ({
@@ -72,7 +91,7 @@ function GraphOrgChartInner({ tree, isExpanded, onToggle, matchedIds }: GraphOrg
style: { stroke: "#e3cddb", strokeWidth: 1.5 },
}));
return { rfNodes, rfEdges };
}, [visibleNodes, visibleEdges, isExpanded, onToggle]);
}, [visibleNodes, visibleEdges, isExpanded, onToggle, onAddUnit, onDeleteUnit, onSelectUnit]);
const [nodes, setNodes, onNodesChange] = useNodesState(rfNodes);
const [edges, setEdges, onEdgesChange] = useEdgesState(rfEdges);
@@ -118,7 +137,7 @@ function GraphOrgChartInner({ tree, isExpanded, onToggle, matchedIds }: GraphOrg
fitView
fitViewOptions={{ padding: 0.2 }}
>
<Background variant={BackgroundVariant.Dots} gap={22} size={1.4} color="#eedde6" />
<Background variant={BackgroundVariant.Dots} gap={22} size={1.4} color="#f0dbd4" />
<Controls showInteractive={false} />
{/* Hidden under lg via CSS: on a phone it would cover a real
fraction of the canvas for little navigational benefit. */}
@@ -126,8 +145,8 @@ function GraphOrgChartInner({ tree, isExpanded, onToggle, matchedIds }: GraphOrg
pannable
zoomable
ariaLabel="Übersichtskarte"
maskColor="rgba(249, 241, 245, 0.75)"
nodeColor={(n) => MINIMAP_COLORS[(n.data as OrgChartNodeDataLike).chartNode.kind] ?? "#d6046e"}
maskColor="rgba(253, 246, 244, 0.75)"
nodeColor={(n) => MINIMAP_COLORS[(n.data as OrgChartNodeDataLike).chartNode.kind] ?? "#164194"}
nodeStrokeWidth={0}
nodeBorderRadius={3}
/>

View File

@@ -1,23 +1,20 @@
"use client";
import { useState } from "react";
import { Printer } from "lucide-react";
import Link from "next/link";
import { SegmentedControl } from "@/components/ui/SegmentedControl";
import type { OpenPositionResolved } from "@/lib/positions";
import { AsOfPicker } from "./AsOfPicker";
import { EmployeeTree } from "./EmployeeTree";
import { PositionTree } from "./PositionTree";
import { ReorgWorkbench } from "./ReorgWorkbench";
import type { OrgDepartment, OrgDivision, OrgEmployee, OrgTeam, ReorgScenarioSummary } from "./types";
import type { OrgEmployee, OrgUnitNode, OrgVacancy } from "./types";
type View = "ma" | "pos" | "reo";
type View = "ma" | "pos";
type OrgChartClientProps = {
employees: OrgEmployee[];
divisions: OrgDivision[];
departments: OrgDepartment[];
teams: OrgTeam[];
openPositions: OpenPositionResolved[];
reorgScenarios: ReorgScenarioSummary[];
units: OrgUnitNode[];
vacancies: OrgVacancy[];
asOf: string;
today: string;
projectedCount: number;
@@ -28,11 +25,8 @@ type OrgChartClientProps = {
export function OrgChartClient({
employees,
divisions,
departments,
teams,
openPositions,
reorgScenarios,
units,
vacancies,
asOf,
today,
projectedCount,
@@ -40,44 +34,33 @@ export function OrgChartClient({
focusId,
}: OrgChartClientProps) {
const [view, setView] = useState<View>("ma");
const isToday = asOf === today;
return (
<div className="flex flex-col gap-4">
<SegmentedControl<View>
value={view}
onChange={setView}
options={[
{ value: "ma", label: "Mitarbeiter" },
{ value: "pos", label: "Positionen" },
{ value: "reo", label: "Reorganisation" },
]}
/>
<div className="flex flex-wrap items-center justify-between gap-3">
<SegmentedControl<View>
value={view}
onChange={setView}
options={[
{ value: "ma", label: "Mitarbeiter" },
{ value: "pos", label: "Organisation" },
]}
/>
{/* Der Stichtag wandert mit: wer eine vergangene Struktur ansieht,
druckt sie auch. */}
<Link
href={asOf === today ? "/orgchart/print" : `/orgchart/print?asOf=${asOf}`}
className="inline-flex items-center gap-2 rounded-md border border-border px-3 py-2 text-sm font-semibold text-ink hover:bg-brand-50 focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500"
>
<Printer className="h-4 w-4" />
Als PDF
</Link>
</div>
{view !== "reo" && (
<AsOfPicker asOf={asOf} today={today} projectedCount={projectedCount} historyStartsAt={historyStartsAt} />
)}
<AsOfPicker asOf={asOf} today={today} projectedCount={projectedCount} historyStartsAt={historyStartsAt} />
{view === "ma" && <EmployeeTree employees={employees} focusId={focusId} />}
{view === "pos" && (
<PositionTree employees={employees} divisions={divisions} departments={departments} teams={teams} openPositions={openPositions} />
)}
{view === "reo" &&
(isToday ? (
<ReorgWorkbench employees={employees} divisions={divisions} departments={departments} teams={teams} reorgScenarios={reorgScenarios} />
) : (
// A reorg planned against a past or projected roster would be
// applied to the *live* org anyway — better to send the user back
// to today than to let them assemble moves from a roster that is
// not the one the change would hit.
<div className="rounded border border-border bg-white p-6 text-sm text-ink-body">
<p className="font-semibold text-ink">Reorganisation nur zum heutigen Stand</p>
<p className="mt-1 text-ink-muted">
Es ist ein abweichender Stichtag gewählt. Reorganisationen wirken immer auf die aktuelle Struktur — wechseln
Sie zurück auf „Heute“, um eine zu planen.
</p>
</div>
))}
{view === "pos" && <PositionTree employees={employees} units={units} vacancies={vacancies} />}
</div>
);
}

View File

@@ -1,7 +1,7 @@
"use client";
import { Handle, Position, type Node, type NodeProps } from "@xyflow/react";
import { Building2, ChevronDown, Plus, UserRound } from "lucide-react";
import { Building2, ChevronDown, Plus, Trash2, UserRound } from "lucide-react";
import Link from "next/link";
import { memo } from "react";
import { Avatar } from "@/components/ui/Avatar";
@@ -14,6 +14,11 @@ export type OrgChartNodeData = {
hasChildren: boolean;
childCount: number;
onToggle: (id: string) => void;
/** Nur in der Struktursicht gesetzt — ohne sie bleibt die Karte unverändert. */
onAddUnit?: (unitId: string) => void;
onDeleteUnit?: (unitId: string) => void;
/** Klick auf die Karte einer Einheit — öffnet ihre Angaben. */
onSelectUnit?: (unitId: string) => void;
};
export type OrgChartRFNode = Node<OrgChartNodeData, "orgNode">;
@@ -25,21 +30,25 @@ const KIND_ACCENT: Record<ChartNodeKind, string> = {
person: "bg-brand-500",
role: "bg-purple-text",
group: "bg-ink-muted",
vacancy: "bg-brand-200",
// Rosa statt einer blassen Blaustufe: eine offene Stelle ist kein
// schwaecheres Abbild einer Person, sondern etwas anderes. Gegen das
// Blau der Person ist der Unterschied auch dann noch zu sehen, wenn
// herausgezoomt nur noch die Streifen uebrig sind.
vacancy: "bg-accent-500",
};
const KIND_SHELL: Record<ChartNodeKind, string> = {
person: "border-border bg-white",
role: "border-border bg-white",
group: "border-border-subtle bg-surface",
vacancy: "border-dashed border-brand-200 bg-brand-50",
vacancy: "border-dashed border-accent-500 bg-accent-50",
};
// React Flow re-renders node components on every pan/zoom frame — memo is
// required, not just tidy, to keep that smooth at a few hundred nodes.
export const OrgChartNode = memo(function OrgChartNode({ id, data }: NodeProps<OrgChartRFNode>) {
const { chartNode, expanded, hasChildren, childCount, onToggle } = data;
const { kind, label, sublabel, avatar, href, vacant, totalReports, absent, coveredBy, coveringFor } = chartNode;
const { chartNode, expanded, hasChildren, childCount, onToggle, onAddUnit, onDeleteUnit, onSelectUnit } = data;
const { kind, label, sublabel, avatar, href, vacant, totalReports, absent, coveredBy, coveringFor, unitId } = chartNode;
const isMatch = chartNode.matched ?? false;
const { width, height } = NODE_DIMENSIONS[kind];
@@ -48,7 +57,7 @@ export const OrgChartNode = memo(function OrgChartNode({ id, data }: NodeProps<O
{kind === "person" && avatar ? (
<Avatar firstName={avatar.firstName} lastName={avatar.lastName} size="sm" />
) : kind === "vacancy" ? (
<span className="flex h-7 w-7 shrink-0 items-center justify-center rounded-full border border-dashed border-brand-200 text-brand-500">
<span className="flex h-7 w-7 shrink-0 items-center justify-center rounded-full border border-dashed border-accent-500 text-accent-700">
<Plus className="h-3.5 w-3.5" />
</span>
) : kind === "role" ? (
@@ -103,6 +112,50 @@ export const OrgChartNode = memo(function OrgChartNode({ id, data }: NodeProps<O
>
<Handle type="target" position={Position.Top} isConnectable={false} className="!invisible" />
{/* Erscheint erst beim Überfahren der Karte: auf achtzig Einheiten wären
achtzig ständig sichtbare Pluszeichen ein Muster und kein Angebot.
Auf Geräten ohne Zeigegerät bleibt er stehen — dort gibt es kein
Überfahren, und unsichtbar hiesse dann unerreichbar. */}
{unitId && (onAddUnit || onDeleteUnit) && (
<span
className="nodrag nopan absolute -right-2.5 -top-2.5 z-10 flex items-center gap-1
opacity-0 transition-opacity group-hover:opacity-100 focus-within:opacity-100
[@media(hover:none)]:opacity-100"
>
{/* Der Papierkorb nur am Blatt. Eine Einheit mit Kindern lässt sich
ohnehin nicht entfernen — der Knopf wäre dort ein Angebot, das
beim Klick eine Absage erteilt, und das ist schlechter als kein
Knopf. Die Datenbank prüft es trotzdem: sie sieht auch
geschlossene Planstellen, die hier gar nicht gezeichnet sind. */}
{onDeleteUnit && !hasChildren && (
<button
type="button"
onClick={() => onDeleteUnit(unitId)}
aria-label={`Einheit ${label} entfernen`}
title="Einheit entfernen"
className="flex h-6 w-6 items-center justify-center rounded-full border border-border bg-white text-ink-muted shadow-sm
transition-colors hover:border-danger-solid hover:bg-danger-solid hover:text-white
focus-visible:outline-2 focus-visible:outline-offset-1 focus-visible:outline-brand-500"
>
<Trash2 className="h-3 w-3" />
</button>
)}
{onAddUnit && (
<button
type="button"
onClick={() => onAddUnit(unitId)}
aria-label={`Einheit unter ${label} anlegen`}
title="Untergeordnete Einheit anlegen"
className="flex h-6 w-6 items-center justify-center rounded-full border border-border bg-white text-ink-muted shadow-sm
transition-colors hover:border-brand-500 hover:bg-brand-500 hover:text-white
focus-visible:outline-2 focus-visible:outline-offset-1 focus-visible:outline-brand-500"
>
<Plus className="h-3.5 w-3.5" />
</button>
)}
</span>
)}
{/* Accent stripe, inset so it follows the card's rounded corner. */}
<span className={`absolute inset-y-1.5 left-0 w-1 rounded-r ${KIND_ACCENT[kind]}`} />
@@ -110,6 +163,18 @@ export const OrgChartNode = memo(function OrgChartNode({ id, data }: NodeProps<O
<Link href={href} className="nodrag nopan flex min-w-0 flex-1 items-center gap-2.5 py-2 pl-3.5 pr-3">
{content}
</Link>
) : unitId && onSelectUnit ? (
// Die ganze Karte, nicht ein Symbol darin: bei achtzig Einheiten ist
// die Fläche das Ziel, das man trifft, ohne hinzusehen.
<button
type="button"
onClick={() => onSelectUnit(unitId)}
aria-label={`Angaben zu ${label}`}
className="nodrag nopan flex min-w-0 flex-1 items-center gap-2.5 py-2 pl-3.5 pr-3 text-left
focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-brand-500"
>
{content}
</button>
) : (
<div className="flex min-w-0 flex-1 items-center gap-2.5 py-2 pl-3.5 pr-3">{content}</div>
)}

Some files were not shown because too many files have changed in this diff Show More