"… und 5 weitere Ereignisse in diesem Zeitraum" was a sentence to read.
It is now a button: click it and the rest unfolds in place, click again
and the card goes back to eight rows.
Until now the only way to see the remaining entries was to narrow the
period or the kinds — which changes the question rather than the answer.
This happens in the browser, not through the URL, unlike the period and
kind filters. Those go through the address because a longer period brings
rows into play that were never loaded; here every entry in the period is
already on the page and the eight was purely presentational. A round trip
would mean waiting for data that is already there, plus a history entry
for something nobody wants to go back to.
The list moved into its own component so the state has somewhere to live.
KIND_LABEL and the item type moved with it, since they only describe this
list.
The button only appears when there is something to unfold, and once open
it offers the way back — otherwise the card stays long for the rest of the
session because somebody looked once.
Verified: 10 tests, five mutation-checked (ignoring the state, dropping
the way back, showing the button with nothing to unfold, losing the
singular, dropping aria-expanded each turn them red). 487 tests,
typecheck and build clean. Not seen in a browser — login goes through the
company account and the database is unreachable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sixty days and all three kinds was a guess, and it was the only one on
offer. Payroll cares about next month; the person filling a vacancy
cares about entries and nothing else. The card now takes a period and a
set of kinds.
The choice lives in the address rather than in the browser, because it
has to: the page is built on the server, and ninety days pulls in rows
that were never loaded at sixty. Filtering client-side would silently
cap the answer at whatever the first query happened to fetch. It also
means a filtered overview can be sent to someone and opened again the
same way.
Deselecting every kind returns to all of them. An empty card is not an
answer to a question nobody asked, and the way back would otherwise be
one click further than the way in. The default period and the full set
are absent from the URL instead of written into it, so a shared link
carries only what was actually chosen.
Anything the address cannot be trusted to hold is rejected: an unknown
period falls back to sixty rather than reaching the query, which would
otherwise be an invitation to ask for ten years of rows through a link.
Eight rows still, with a count of what did not fit underneath — this is
an overview, and the employee list is where lists belong.
Not verified in a browser: the built-in preview has no company sign-in,
so the page redirects to the login before it renders. Types, lint and
386 tests pass, and the filter's behaviour is covered directly.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- components/hire/: 4-step Hire Wizard (Person/Position/Vertrag/
Zusammenfassung) matching sec4.4, with a HireWizardProvider context so it
can be opened both from the global "+ Neueinstellung" button and from a
"Fortsetzen" link on a saved draft.
- actions/hireDrafts.ts: save/delete hire_drafts (owner-scoped RLS already
in place from Phase 1). Dashboard now shows the "Entwuerfe" card the
Phase 1 plan deferred, since the wizard it depends on now exists.
- lib/positions.ts: shared open-positions loader (position number, org
breadcrumb, resolved manager name) used by both the wizard and (later)
the Positions page.
Two real bugs found via live testing and fixed in supabase/functions.sql:
1. hire_employee/rehire_employee: a two-branch CASE returning bare string
literals defaults to `text`, not the target enum, so `status = case
when ... then 'Geplant' else 'Aktiv' end` failed against the
employment_status column. Fixed with an explicit ::employment_status
cast on the whole CASE expression.
2. Postgres precedence gotcha: ->> and || sit at the *same* precedence
tier and left-associate, so `payload->>'first_name' || ' ' ||
payload->>'last_name'` does not group the way it reads - it tries to
apply ->> to an intermediate text value and fails with "operator does
not exist: text ->> unknown". Fixed by parenthesizing every ->>'...'
expression that participates in a || chain.
Also fixed: hire_employee referenced v_position.title outside the branch
that assigns v_position, raising "record not assigned" whenever a hire
wasn't tied to a position_id; extracted a v_job_title variable instead.
Verified live end-to-end: wizard search -> select position -> submit
creates the employee, closes the position, and writes matching
employee_history + audit_log rows atomically.
