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.
Andrei Laas
38f8c99968