Maximilian Stubhan
37bb107cd4
Visual - `--radius: 8px` in @theme collapsed Tailwind v4's whole radius scale onto a single value: `rounded` and `rounded-lg` both measured 8px, so a chip, an input and a card could not be told apart. Named steps restore the gradation (6 / 8 / 12px, measured in the browser). - Cards were a 1px border and nothing else. Added warm, brand-tinted elevation tokens — a neutral black shadow over the pink surface reads as dirt — in three steps for cards, dropdowns and overlays, collected behind components/ui/Card.tsx so the 26 hand-copied card class chains have one definition. - KPI tiles lead with the number and carry a tone accent; tables got denser rows, subtle row rules (the full border strength made 800 rows read as a grid), tabular figures in numeric columns and a brand-tinted hover. KPI tiles now link to the view that shows what they count. Making those links honest surfaced two reasons the numbers did not agree with their destinations: - The dashboard read `employees.status`, while every report derives status from entry/exit/karenz dates. A hire whose start date had passed before the cron ran was counted differently on the two pages. The dashboard now uses the same derivation — and one query instead of five. - Eintritte/Austritte counted `entry_date`/`exit_date` while the linked report counts `employee_history`; rehire_employee sets entry_date but logs the event as 'Wiedereintritt', so rehires were missing from the target. Both now count history events. - The employee list filtered on the status column, so it disagreed too. It now filters on derived status in SQL (lib/employee-status-filter.ts). That restates deriveStatusAsOf a second time, in a second language, so an integration test runs both over the full roster and requires identical id sets — drift here is otherwise invisible. Status semantics, per the domain correction: "aktiv" means status Aktiv alone. Karenz is employed but not active, and has its own tile. The active headcount, FTE (Karenz contributes no capacity) and the division bars all follow that; the bars are labelled "Aktive nach Bereich" rather than "Headcount" to say so. The employee filter still offers the combination, named after the two statuses it selects instead of calling the pair active. DEFAULT_STATUSES in lib/reports.ts is deliberately left at Aktiv + Karenz: it governs what the Berichte page shows without an explicit status filter, and therefore what already-saved reports and exports mean.
80 lines
3.0 KiB
TypeScript
80 lines
3.0 KiB
TypeScript
import { describe, expect, it } from "vitest";
|
|
import { applyDerivedStatusFilter } from "@/lib/employee-status-filter";
|
|
import { todayIso } from "@/lib/format";
|
|
import { deriveStatusAsOf } from "@/lib/reports";
|
|
import type { EmploymentStatus } from "@/lib/supabase/types";
|
|
import { adminClient } from "./helpers";
|
|
|
|
// lib/employee-status-filter.ts is a SQL restatement of deriveStatusAsOf():
|
|
// the employee list pages in the database and cannot derive status in JS, so
|
|
// the same rule exists twice. Two copies of a rule drift, and the drift is
|
|
// invisible — a dashboard tile and the list it links to just quietly show
|
|
// different numbers.
|
|
//
|
|
// Only a real database can settle it, so this runs both over the whole
|
|
// seeded roster and demands the same set of ids.
|
|
describe("derived status filter matches deriveStatusAsOf", () => {
|
|
const asOf = todayIso();
|
|
|
|
async function idsFromDatabase(statuses: EmploymentStatus[]): Promise<Set<string>> {
|
|
const query = adminClient.from("employees").select("id");
|
|
const { data, error } = await applyDerivedStatusFilter(query, statuses, asOf);
|
|
if (error) throw new Error(error.message);
|
|
return new Set((data ?? []).map((r) => r.id));
|
|
}
|
|
|
|
async function idsFromDerivation(statuses: EmploymentStatus[]): Promise<Set<string>> {
|
|
const { data, error } = await adminClient
|
|
.from("employees")
|
|
.select("id, entry_date, exit_date, karenz_start_date, karenz_return_date");
|
|
if (error) throw new Error(error.message);
|
|
return new Set((data ?? []).filter((e) => statuses.includes(deriveStatusAsOf(e, asOf))).map((e) => e.id));
|
|
}
|
|
|
|
async function expectSameSet(statuses: EmploymentStatus[]) {
|
|
const [fromDb, fromJs] = await Promise.all([idsFromDatabase(statuses), idsFromDerivation(statuses)]);
|
|
|
|
const onlyInDb = [...fromDb].filter((id) => !fromJs.has(id));
|
|
const onlyInJs = [...fromJs].filter((id) => !fromDb.has(id));
|
|
|
|
expect({ statuses, onlyInDb: onlyInDb.slice(0, 5), onlyInJs: onlyInJs.slice(0, 5) }).toEqual({
|
|
statuses,
|
|
onlyInDb: [],
|
|
onlyInJs: [],
|
|
});
|
|
// Guards against a filter so narrow it matches nothing and passes
|
|
// trivially.
|
|
expect(fromJs.size).toBeGreaterThan(0);
|
|
}
|
|
|
|
it("agrees for Aktiv + Karenz — the definition the dashboard headcount uses", async () => {
|
|
await expectSameSet(["Aktiv", "Karenz"]);
|
|
});
|
|
|
|
it("agrees for Aktiv alone", async () => {
|
|
await expectSameSet(["Aktiv"]);
|
|
});
|
|
|
|
it("agrees for Karenz alone", async () => {
|
|
await expectSameSet(["Karenz"]);
|
|
});
|
|
|
|
it("agrees for Geplant", async () => {
|
|
await expectSameSet(["Geplant"]);
|
|
});
|
|
|
|
it("agrees for Ausgetreten", async () => {
|
|
await expectSameSet(["Ausgetreten"]);
|
|
});
|
|
|
|
it("returns everyone when no status is selected", async () => {
|
|
const { count: total } = await adminClient.from("employees").select("id", { count: "exact", head: true });
|
|
const { count: filtered } = await applyDerivedStatusFilter(
|
|
adminClient.from("employees").select("id", { count: "exact", head: true }),
|
|
[],
|
|
asOf
|
|
);
|
|
expect(filtered).toBe(total);
|
|
});
|
|
});
|