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.
77 lines
3.3 KiB
TypeScript
77 lines
3.3 KiB
TypeScript
import type { EmploymentStatus } from "./supabase/types";
|
|
|
|
// The SQL counterpart of deriveStatusAsOf() in lib/reports.ts.
|
|
//
|
|
// The employee list is paged in the database, so it cannot derive status in
|
|
// JavaScript the way the reports and the dashboard do — it has to filter on
|
|
// the server. Filtering on the `employees.status` column instead was the
|
|
// reason a dashboard tile and the list it links to could disagree: that
|
|
// column holds whatever the last mutation or cron run wrote, while every
|
|
// other surface computes status from entry/exit/karenz dates.
|
|
//
|
|
// Kept deliberately close to deriveStatusAsOf, clause for clause:
|
|
//
|
|
// entry_date > asOf -> Geplant
|
|
// exit_date <= asOf -> Ausgetreten
|
|
// karenz window covers asOf -> Karenz
|
|
// otherwise -> Aktiv
|
|
//
|
|
// tests/integration/employee-status-filter.test.ts asserts the two agree
|
|
// against a real database, which is the only place that can prove it.
|
|
|
|
type Filterable = {
|
|
gt: (column: string, value: string) => Filterable;
|
|
lte: (column: string, value: string) => Filterable;
|
|
gte: (column: string, value: string) => Filterable;
|
|
or: (filters: string) => Filterable;
|
|
is: (column: string, value: null) => Filterable;
|
|
not: (column: string, operator: string, value: null) => Filterable;
|
|
};
|
|
|
|
/** True once the person has started and has not left yet. */
|
|
function employed<Q extends Filterable>(query: Q, asOf: string): Q {
|
|
return query.lte("entry_date", asOf).or(`exit_date.is.null,exit_date.gt.${asOf}`) as Q;
|
|
}
|
|
|
|
/**
|
|
* Narrows a PostgREST query to the employees whose *derived* status on
|
|
* `asOf` is one of `statuses`. Only the combinations the UI offers are
|
|
* supported; anything else is left unfiltered rather than silently applying
|
|
* a wrong one.
|
|
*/
|
|
export function applyDerivedStatusFilter<Q extends Filterable>(query: Q, statuses: EmploymentStatus[], asOf: string): Q {
|
|
const wanted = new Set(statuses);
|
|
if (wanted.size === 0) return query;
|
|
|
|
// A single non-employed status is a straight date comparison.
|
|
if (wanted.size === 1 && wanted.has("Geplant")) return query.gt("entry_date", asOf) as Q;
|
|
if (wanted.size === 1 && wanted.has("Ausgetreten")) return query.not("exit_date", "is", null).lte("exit_date", asOf) as Q;
|
|
|
|
const wantsAktiv = wanted.has("Aktiv");
|
|
const wantsKarenz = wanted.has("Karenz");
|
|
|
|
if (wantsAktiv && wantsKarenz && wanted.size === 2) {
|
|
// Everyone employed today, whether or not they are on leave.
|
|
return employed(query, asOf);
|
|
}
|
|
|
|
if (wantsKarenz && !wantsAktiv && wanted.size === 1) {
|
|
return employed(query, asOf)
|
|
.not("karenz_start_date", "is", null)
|
|
.lte("karenz_start_date", asOf)
|
|
.or(`karenz_return_date.is.null,karenz_return_date.gt.${asOf}`) as Q;
|
|
}
|
|
|
|
if (wantsAktiv && !wantsKarenz && wanted.size === 1) {
|
|
// Employed but *not* inside a karenz window: either no start date, a
|
|
// start still ahead, or a return that has already happened.
|
|
return employed(query, asOf).or(
|
|
`karenz_start_date.is.null,karenz_start_date.gt.${asOf},karenz_return_date.lte.${asOf}`
|
|
) as Q;
|
|
}
|
|
|
|
// Mixed selections spanning employed and non-employed states have no UI
|
|
// path today; filtering on a guess would be worse than not filtering.
|
|
return query;
|
|
}
|