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.
