Let the employee list be sorted A-Z or Z-A
Some checks failed
CI / Lint, Typen, Tests, Build (push) Failing after 6m12s
CI / Integrationstests (echtes Postgres) (push) Failing after 5m29s

Sorting lives in the URL, not the browser. The list is built on the
server and fetched a page at a time, so a client-side sort would only
reorder the fifteen rows on screen — with 867 people that promises an
alphabetical list and delivers something else on page 2.

The sort key is the surname, because that is how the column reads:
"Aigner, Manuel", and whoever looks for someone looks under A. Postgres
runs with the Austrian collation, so Ö sorts with O rather than at the
end of the alphabet.

Only the surname reverses. The id stays ascending: it decides nothing
except ties, and it exists to keep the order total across page
boundaries. Reversing it too would still be deterministic but would flip
the fourteen Winklers relative to each other for no reason anyone asked
for.

The select sits in the filter bar rather than in a clickable column
header — a header would suggest it sorts what is on screen.

Verified: compiled SQL is `order by last_name desc, id` for Z-A; the
parse and direction rules are covered by tests that were mutation-checked
(breaking each rule turns them red). Not verified in the browser — the
login goes through the company account, and the Supabase instance no
longer resolves.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-09-07 10:02:15 +02:00
parent af947f094d
commit 5c310c3a58
4 changed files with 112 additions and 2 deletions

View File

@@ -9,6 +9,7 @@ import { currentUserId } from "@/lib/auth/session";
import { sql, withUser } from "@/lib/db";
import { jsonArrayFrom, jsonObjectFrom } from "@/lib/db/json";
import { istPersonalnummer, suchMuster } from "@/lib/employee-search";
import { parseSortierung, richtung } from "@/lib/employee-sort";
import { derivedStatusFilter } from "@/lib/employee-status-filter";
import { fmtDate, fmtName, todayIso } from "@/lib/format";
import { breadcrumbLabel, divisionOf, loadOrgMaps, subtreeOf, unitOf, type OrgEb } from "@/lib/org";
@@ -22,6 +23,7 @@ type SearchParams = {
division?: string;
status?: string;
location?: string;
sort?: string;
page?: string;
};
@@ -35,6 +37,9 @@ function pageHref(params: SearchParams, page: number): string {
if (params.division) sp.set("division", params.division);
if (params.status) sp.set("status", params.status);
if (params.location) sp.set("location", params.location);
// Ohne das kippte die Liste beim Blättern zurück auf A–Z, und Seite 2
// zeigte Namen, die auf Seite 1 schon standen.
if (params.sort) sp.set("sort", params.sort);
sp.set("page", String(page));
return `/employees?${sp.toString()}`;
}
@@ -42,6 +47,7 @@ function pageHref(params: SearchParams, page: number): string {
export default async function EmployeesPage({ searchParams }: EmployeesPageProps) {
const params = await searchParams;
const page = Math.max(1, Number(params.page ?? "1") || 1);
const sortierung = parseSortierung(params.sort);
const today = todayIso();
// Comma-separated, so a dashboard tile can link here with the same
@@ -176,8 +182,9 @@ export default async function EmployeesPage({ searchParams }: EmployeesPageProps
])
// Nach id als zweitem Kriterium: bei gleichem Nachnamen wäre die
// Reihenfolge sonst unbestimmt, und dieselbe Person könnte auf zwei
// Seiten erscheinen oder auf keiner.
.orderBy("last_name")
// Seiten erscheinen oder auf keiner. Die Kennung bleibt deshalb
// aufsteigend, auch wenn der Nachname sich dreht.
.orderBy("last_name", richtung(sortierung))
.orderBy("id")
.limit(PAGE_SIZE)
.offset((page - 1) * PAGE_SIZE)