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.

db/migrations/20260917110000_ereignis_uebernahme.sql

@@ -0,0 +1,55 @@
+-- „Übernahme" als eigenes Ereignis.
+--
+-- Aus dem Gespräch vom 17.09.2026: wenn eine Person von `Extern` auf `Intern`
+-- wechselt, ist das eine Übernahme — ein Vorgang wie Neueinstellung,
+-- Wiedereinstellung oder Versetzung, und er soll als solcher im Protokoll
+-- stehen und im Berichtemanager auswertbar sein.
+--
+-- Der umgekehrte Weg (Intern auf Extern) bekommt ausdrücklich **kein**
+-- Ereignis: eine Übernahme zurückzunehmen gibt es fachlich nicht, und ein
+-- Ereignis dafür wäre eine Erfindung.
+--
+-- ═══ Warum das hier allein steht ═══════════════════════════════════
+--
+-- Dieselbe Begründung wie bei Migration 20260910140000 (Lehrling):
+-- scripts/migrate.mjs fährt jede Migration in einer Transaktion. Seit
+-- PostgreSQL 12 darf `add value` darin stehen — **benutzen** lässt sich der
+-- neue Wert in derselben Transaktion aber nicht. Die Logik, die ihn schreibt,
+-- steht deshalb in der nächsten Datei; hier ist der Wert nach dem Commit
+-- verfügbar.
+--
+-- Und wie dort gilt: ein Enum-Wert lässt sich nicht wieder entfernen. In
+-- dieser Datei steht darum nichts weiter, was man gleichzeitig zurücknehmen
+-- wollen könnte.
+
+alter type history_event_type add value if not exists 'Übernahme';
+
+-- ═══ Gegenprobe ═══════════════════════════════════════════════════
+--
+-- Über pg_enum, wo die Beschriftung schlichter Text ist: ein Vergleich gegen
+-- 'Übernahme'::history_event_type scheiterte in derselben Transaktion mit
+-- „unsafe use of new value".
+do $$
+declare
+  anzahl int;
+begin
+  if not exists (
+    select 1
+      from pg_enum e
+      join pg_type t on t.oid = e.enumtypid
+     where t.typname = 'history_event_type' and e.enumlabel = 'Übernahme'
+  ) then
+    raise exception 'history_event_type kennt Übernahme nicht.';
+  end if;
+
+  -- Die elf bisherigen Werte müssen stehen bleiben. Ein Enum, das statt
+  -- zwölf Werten nur noch den neuen trägt, hätte jede Historienzeile
+  -- unlesbar gemacht.
+  select count(*) into anzahl
+    from pg_enum e
+    join pg_type t on t.oid = e.enumtypid
+   where t.typname = 'history_event_type';
+  if anzahl <> 12 then
+    raise exception 'history_event_type hat % Werte, erwartet werden 12.', anzahl;
+  end if;
+end $$;