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.
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.
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.
