Andrei Laas
6ab78d4b27
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.
56 lines
2.3 KiB
SQL
56 lines
2.3 KiB
SQL
-- „Ü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 $$;
|