**Das Logo auf der Anmeldeseite.** Statt des Schriftzugs stand dort der Ersatztext "Manner". Die SVG-Fassung war gueltiges XML, lag im Repository und war committet — warum sie im Betrieb nicht geladen wurde, laesst sich von hier aus nicht feststellen; dafuer braucht es die Antwort des Servers auf die URL. Statt das weiter zu raten, faellt die Angriffsflaeche weg: es gibt jetzt eine Datei, manner-logo.png, der Schriftzug mit durchsichtigem Grund. Kein XML, kein Beschnitt, kein eingebackenes Feld. Das Blau darin ist #164194, also der Wert aus §1.1. Damit verschwinden auch die zwei Fassungen. §1.2 laesst den Schriftzug nur zur Gaenze auf Rosa zu, und das Manual kennt dafuer zwei Lagen: auf Weiss gehoert er nach §4.1 in ein rechteckiges rosa Feld, in einem grossflaechigen rosa Umfeld nach §3.1 nur mit Freiraum. Beides entsteht jetzt aus derselben Datei — das Feld zeichnet das Bauteil, aus derselben Polsterung wie den Freiraum. **Der Filter "Geplant" fand Ausgetretene.** Die Ableitung pruefte den Eintritt vor dem Austritt, und wer einen Eintritt in der Zukunft hatte, galt als geplant — auch wenn der Austritt laengst verbucht war. Das trifft genau den No-Show (Migration 20260814100000): eingestellt, nie erschienen, Austritt vor dem Eintrittstag. Im Bestand sind das Zeilen mit Eintritt 01.10.2026, die der Filter mitzaehlte, waehrend die Liste daneben "Ausgetreten" anzeigte. employees.status, das die SQL-Funktion beim Austritt setzt, sagte von Anfang an das Richtige; falsch war die Ableitung in der Anwendung. Ein abgeschlossener Austritt wird jetzt zuerst geprueft: er beendet das Verhaeltnis, gleichgueltig ob der Eintritt schon war oder noch kommt. Ein Austritt, der selbst noch bevorsteht, nimmt den Eintritt nicht zurueck — wer am 01.10. anfaengt und am 31.12. aufhoert, ist heute geplant. Die SQL-Fassung in lib/employee-status-filter.ts bildet dieselbe Reihenfolge ab. Keine Migration: beide Fassungen der Regel liegen in TypeScript. In SQL wird nur der Karenz-Teil wiederholt, fuer die Fuehrungslinie, und der ist nicht betroffen. **Die vier Anstehend-Chips.** Zwei davon standen in der Markenfarbe, weil die Farbe ueber den Beschriftungstext aus der Tabelle der Protokoll-Aktionen geholt wurde — und die kennt eine andere Sprache: "Neueinstellung", nicht "Eintritt". Wer dort nicht steht, bekam den neutralen Chip. Ein Nachschlagen, das bei einem Fehlschlag still etwas Plausibles liefert, faellt eben nicht auf. Die vier haben jetzt eine eigene Zuordnung, nach dem Wert verschluesselt und nicht nach der Beschriftung: Eintritt gruen, Austritt rot, Wiedervorlage gelb, Rueckkehr violett. Tuerkis waere fuer die Rueckkehr die naheliegendere Lesart gewesen, kam gegen das Gruen des Eintritts aber nur auf dE 13.0; Violett steht mit 30.8 eindeutig daneben. Schwaechstes Paar der vier: 14.2, schwaechster Kontrast 5.49:1. Zehn Tests dazu, darunter die drei Faelle, an denen der Filter gescheitert war. Lint, Typen, Schemaabgleich, 562 Tests und der Build sind sauber. Im Browser nicht gesehen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
101 lines
3.9 KiB
TypeScript
101 lines
3.9 KiB
TypeScript
import { DummyDriver, Kysely, PostgresAdapter, PostgresIntrospector, PostgresQueryCompiler } from "kysely";
|
|
import { describe, expect, it } from "vitest";
|
|
import type { Schema } from "@/lib/db/schema";
|
|
import { derivedStatusFilter } from "@/lib/employee-status-filter";
|
|
import { deriveStatusAsOf } from "@/lib/reports";
|
|
import type { EmploymentStatus } from "@/lib/types";
|
|
|
|
// Die Liste filtert in der Datenbank, weil sie dort auch blättert. Der Filter
|
|
// ist damit die einzige Stelle, an der der Status *nicht* von
|
|
// deriveStatusAsOf() kommt, sondern von einer zweiten Fassung derselben Regel
|
|
// in SQL. Zwei Fassungen driften, und diese hier taten es: „Geplant" fragte
|
|
// nur nach dem Eintrittsdatum und zählte die No-Shows mit — Leute mit einem
|
|
// Eintritt in der Zukunft, deren Austritt längst verbucht war.
|
|
//
|
|
// tests/integration/employee-status-filter.test.ts hält die beiden gegen eine
|
|
// echte Datenbank, läuft aber mangels Seed nicht in der CI. Deshalb hier
|
|
// zweierlei ohne Datenbank: die erzeugte Abfrage lesen, und die
|
|
// TypeScript-Ableitung an denselben Fällen prüfen.
|
|
|
|
const db = new Kysely<Schema>({
|
|
dialect: {
|
|
createAdapter: () => new PostgresAdapter(),
|
|
createDriver: () => new DummyDriver(),
|
|
createIntrospector: (d) => new PostgresIntrospector(d),
|
|
createQueryCompiler: () => new PostgresQueryCompiler(),
|
|
},
|
|
});
|
|
|
|
const STICHTAG = "2026-09-15";
|
|
|
|
/** Die where-Klausel, die für eine Statusauswahl herauskommt. */
|
|
function bedingung(statuses: EmploymentStatus[]): string {
|
|
return db
|
|
.selectFrom("employees")
|
|
.select("id")
|
|
.where((eb) => derivedStatusFilter(eb, statuses, STICHTAG) ?? eb.val(true))
|
|
.compile()
|
|
.sql.replace(/^.*? where /s, "")
|
|
.replace(/\s+/g, " ");
|
|
}
|
|
|
|
describe("derivedStatusFilter — Geplant", () => {
|
|
it("fragt nach dem Eintritt in der Zukunft", () => {
|
|
expect(bedingung(["Geplant"])).toContain('"entry_date" >');
|
|
});
|
|
|
|
// Die eigentliche Zusicherung: ohne diese Hälfte war der Filter falsch.
|
|
it("schliesst aus, wessen Austritt schon vollzogen ist", () => {
|
|
const sql = bedingung(["Geplant"]);
|
|
expect(sql).toContain('"exit_date" is null');
|
|
expect(sql).toContain('"exit_date" >');
|
|
});
|
|
});
|
|
|
|
describe("derivedStatusFilter — Ausgetreten", () => {
|
|
it("verlangt ein Austrittsdatum, das erreicht ist", () => {
|
|
const sql = bedingung(["Ausgetreten"]);
|
|
expect(sql).toContain('"exit_date" is not null');
|
|
expect(sql).toContain('"exit_date" <=');
|
|
});
|
|
});
|
|
|
|
describe("derivedStatusFilter — nicht abgedeckte Auswahl", () => {
|
|
it("filtert lieber gar nicht als falsch", () => {
|
|
// Eine Mischung aus beschäftigt und nicht beschäftigt hat keinen Weg in
|
|
// der Oberfläche; geraten wird dafür nichts.
|
|
expect(derivedStatusFilter({} as never, ["Aktiv", "Ausgetreten"], STICHTAG)).toBeNull();
|
|
expect(derivedStatusFilter({} as never, [], STICHTAG)).toBeNull();
|
|
});
|
|
});
|
|
|
|
// Dieselben Fälle noch einmal gegen die TypeScript-Ableitung: was der Filter
|
|
// findet und was die Liste daneben anzeigt, muss dieselbe Person meinen.
|
|
describe("Filter und Anzeige meinen dasselbe", () => {
|
|
const basis = { karenz_start_date: null, karenz_return_date: null };
|
|
|
|
const faelle: { was: string; e: Parameters<typeof deriveStatusAsOf>[0]; erwartet: EmploymentStatus }[] = [
|
|
{
|
|
was: "No-Show: Eintritt in der Zukunft, Austritt bereits vollzogen",
|
|
e: { ...basis, entry_date: "2026-10-01", exit_date: "2026-09-10" },
|
|
erwartet: "Ausgetreten",
|
|
},
|
|
{
|
|
was: "geplanter Eintritt ohne Austritt",
|
|
e: { ...basis, entry_date: "2026-10-01", exit_date: null },
|
|
erwartet: "Geplant",
|
|
},
|
|
{
|
|
was: "geplanter Eintritt mit Befristung, beides in der Zukunft",
|
|
e: { ...basis, entry_date: "2026-10-01", exit_date: "2026-12-31" },
|
|
erwartet: "Geplant",
|
|
},
|
|
];
|
|
|
|
for (const { was, e, erwartet } of faelle) {
|
|
it(was, () => {
|
|
expect(deriveStatusAsOf(e, STICHTAG)).toBe(erwartet);
|
|
});
|
|
}
|
|
});
|