Andrei Laas
4dc27bf212
Die neue Kachel "Aktives Dienstverhaeltnis" verlinkte auf
?status=Aktiv&status=Karenz. Die Mitarbeiterliste liest den Parameter aber
als *eine* Zeichenkette und trennt selbst an Kommas — zweimal uebergeben
macht Next daraus ein Array, und `.split(",")` lief dagegen. Sichtbar war
nur "Diese Ansicht konnte nicht geladen werden".
Die Kachel schreibt jetzt status=Aktiv,Karenz. Dazu glaettet die Seite alle
ihre Parameter: eine Adresse kommt nicht nur aus der eigenen Anwendung, sie
steht in Lesezeichen und in E-Mails, und ?q=a&q=b haette sie genauso
gefaellt.
Zwei Anmerkungen von Max:
* Die Reihenfolge der Wochentage wurde beim Speichern mitgenommen — "Mo,
Di" und "Di, Mo" waren zwei Werte fuer dieselbe Aussage. Da
change_employee_data die Arbeitstage als zusammengefuegte Zeichenkette
vergleicht, erzeugte jedes Nachsehen und Wiederherstellen eine
Vertragsaenderung in der Akte und einen Protokolleintrag — ueber nichts.
Jetzt sortiert gespeichert (lib/wochentage.ts, an einer Stelle statt in
vier Kopien), auch im Massenimport. Der Bestand richtet sich beim
naechsten Speichern von selbst.
* "Beguenstigt behindert" steht jetzt als eingerueckter Unterpunkt des
Kuendigungsschutzes statt als eigener Block daneben. In der Datenbank
bleiben es getrennte Felder, und das mit Absicht: eine Kopplung liesse
jede Korrektur am Personenkreis scheitern, solange der Grad noch
dransteht.
43 lines
2.2 KiB
TypeScript
43 lines
2.2 KiB
TypeScript
import type { Weekday } from "./types";
|
|
|
|
// Die Wochentage in ihrer natürlichen Reihenfolge — an einer Stelle.
|
|
//
|
|
// Sie stand bisher viermal im Baum: in RoleEmploymentFields, in lib/reports,
|
|
// im Mitarbeiter-Export und in lib/import/schema. Vier Kopien einer Liste,
|
|
// die sich nie ändert, sind für sich genommen harmlos; was nicht harmlos war,
|
|
// ist die fehlende fünfte Verwendung — das Sortieren beim Speichern.
|
|
//
|
|
// ── Warum sortiert gespeichert wird ─────────────────────────────────
|
|
//
|
|
// `work_days` wurde in **Klickreihenfolge** abgelegt (so stand es auch in
|
|
// docs/datenkatalog.md, als bewusste Entscheidung). Damit sind „Mo, Di" und
|
|
// „Di, Mo" zwei verschiedene Werte für dieselbe Aussage, und
|
|
// change_employee_data vergleicht die alte mit der neuen Fassung über
|
|
// `array_to_string(work_days, ', ')`. Wer die Tage nur noch einmal anklickte,
|
|
// um sie zu prüfen, erzeugte damit eine Vertragsänderung in der Personalakte
|
|
// und einen Eintrag im Protokoll — über nichts.
|
|
//
|
|
// Die Reihenfolge trägt keine Bedeutung: welche Tage jemand arbeitet, ist
|
|
// eine Menge, keine Folge. Sortiert gespeichert fällt der Scheinunterschied
|
|
// weg, ohne dass der Vergleich in SQL etwas davon wissen muss.
|
|
//
|
|
// Der Bestand kann noch unsortierte Zeilen enthalten (aus dem Massenimport
|
|
// oder von früher). Sie richten sich beim nächsten Speichern von selbst —
|
|
// und *dieser* eine Eintrag in der Historie ist dann keine Falschmeldung,
|
|
// sondern die Aufzeichnung genau dieser Berichtigung.
|
|
|
|
export const WOCHENTAGE: readonly Weekday[] = ["Mo", "Di", "Mi", "Do", "Fr", "Sa", "So"] as const;
|
|
|
|
const RANG = new Map(WOCHENTAGE.map((t, i) => [t, i] as const));
|
|
|
|
/**
|
|
* Die Tage in Wochenreihenfolge, ohne Dubletten.
|
|
*
|
|
* Unbekanntes wandert ans Ende statt verworfen zu werden: die Spalte ist ein
|
|
* `text[]` ohne Prüfung, und was der Massenimport einmal hineingeschrieben
|
|
* hat, soll eine Sortierung nicht stillschweigend löschen.
|
|
*/
|
|
export function sortiereWochentage<T extends string>(tage: readonly T[]): T[] {
|
|
return [...new Set(tage)].sort((a, b) => (RANG.get(a as Weekday) ?? 99) - (RANG.get(b as Weekday) ?? 99));
|
|
}
|