Files
F-r-ldraledigplannerare/frontend/e2e/support/api.ts
T
jacobh2 782415122d Separate user intent from planner output via day assertions
The calendar mixed two kinds of truth in one table. `planned_leave_day` was
simultaneously the allocator's output cache, the user's override store
(`is_pinned`, plus ad-hoc rows with no `wish_id`), and the resource ledger that
analytics and the age-4 maths read. The planner therefore had to ask "am I
allowed to touch this row?" on every sync, and got it wrong at the edges.

Every user assertion is now one `day_assertion` row — a concrete `day_type`
replaces a pinned day, a row with no `wish_id` replaces an ad-hoc day, and
`day_type='none'` replaces `planned_day_exclusion`. `planned_leave_day` becomes
purely derived with a single writer, and `PlanningService.pinned_keys()` is the
single answer to "is this day pinned", used by the allocator's loader, by
`sync_plan` and by the read router alike.

On top of that, every calendar band is now a real event: an ad-hoc band opens
the same full editor as a wish-backed one and saving it promotes it to a
`LeaveWish`, so it can be named, repeated yearly, assigned to either or both
parents, and handed to the planner. "Planering" is a `moveable` toggle plus a
from/to month bound plus a separate lock/unlock action on the days themselves,
replacing a three-rung ladder whose "planner decides" rung set a search window
equal to the drawn dates and so could never move anything.

Bugs found and fixed along the way:

- The plan erased its own history. Fixed windows clip to today, so an elapsed
  auto-placed day fell into `stale_keys` and was deleted on the next sync —
  and a background sync runs on every workspace load. Past rows are now frozen
  and counted as spent.
- Migration 010's downgrade silently destroyed every pinned day and exclusion
  (`is_pinned` returned as DEFAULT 0, the exclusion table came back empty,
  exit 0, no warning). It now reconstructs both from `day_assertion`, and 009
  itemises what it cannot recover before dropping the table.
- Deleting a period left its assertions behind, locking those dates forever
  with no UI path to clear them. Wish deletion now clears them by `wish_id`.
- `DayAssertionService` and `LeaveWishService` committed multi-statement writes
  without a transaction; a crash mid-write diverged the tables or half-deleted
  a series. Both now run in a unit of work.
- A sibling year's shortfall was never surfaced: the toast only inspected the
  edited occurrence's outcome, so a fully unfunded later year rendered as an
  empty band with no warning.
- A flexible window whose bound had entirely elapsed was dropped from the
  proposal with no outcome at all. It now reports as `unplaced`.
- Unlocking a period deleted its days instead of returning them to the planner.
- The e2e global setup posted to a route deleted in this change, which would
  have failed the whole suite before its first test.

Gates: backend 938 tests / 91% coverage, frontend 1351 / 97.4 | 92.2 | 94.37 |
97.4. Migrations 009 and 010 audited against a hand-built realistic database:
the upgrade reconciles exactly and a constraint violation fails safe, leaving
the schema at 008.

Not complete. Step 4's toggle, month picker and lock/unlock action are verified
by browser walk and unit tests, but the partial-lock readout was not exercised.
`ideas.md` §7 adds a full plan for the vacation-forfeiture defect (the planner
detects expiring days and then does nothing about them) — not implemented here.
Remaining smaller items are listed in the session's restructure notes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T4wjgbVL4HAC5Rdaw75VbV
2026-09-21 07:20:14 +02:00

126 lines
4.0 KiB
TypeScript

/**
* Minimal, dependency-free HTTP helpers for talking to the backend directly
* (bypassing the browser) during E2E setup and ground-truth assertions.
*
* Deliberately hits the backend at 127.0.0.1:8000, not through the Vite
* proxy: these calls run in plain Node (global-setup) or alongside a
* Playwright test (spec files), never inside a browser page, so there is no
* CORS concern and no need for the proxy or the httpOnly refresh cookie —
* just a Bearer access token obtained via `apiLogin`.
*/
export const API_BASE = 'http://127.0.0.1:8000'
// Seeded by `backend/scripts/seed_demo.py` — see that file's module
// docstring. Not a secret: dev-only, fixed, printed by the script itself.
export const DEMO_EMAIL = 'demo@example.com'
export const DEMO_PASSWORD = 'DemoPass123!'
export async function waitForBackendHealth(timeoutMs = 60_000): Promise<void> {
const healthUrl = `${API_BASE}/health`
const deadline = Date.now() + timeoutMs
let lastError: unknown = null
while (Date.now() < deadline) {
try {
const res = await fetch(healthUrl)
if (res.ok) return
} catch (err) {
lastError = err
}
await new Promise((resolve) => setTimeout(resolve, 500))
}
throw new Error(`Backend never reported healthy at ${healthUrl}: ${String(lastError)}`)
}
async function parseJsonOrThrow<T>(res: Response, what: string): Promise<T> {
if (!res.ok) {
throw new Error(`${what} failed: ${res.status} ${await res.text()}`)
}
return (await res.json()) as T
}
interface LoginResponse {
access_token: string
}
export async function apiLogin(email: string, password: string): Promise<string> {
const res = await fetch(`${API_BASE}/api/auth/login`, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ email, password }),
})
const data = await parseJsonOrThrow<LoginResponse>(res, 'login')
return data.access_token
}
export interface ApiChild {
id: string
name: string
birth_date: string
}
export interface ApiUserContext {
personal_data_uuid: string
workspace_id: string
parent_name: string
children: ApiChild[]
}
export async function apiGetContext(token: string): Promise<ApiUserContext> {
const res = await fetch(`${API_BASE}/api/auth/context`, {
headers: { Authorization: `Bearer ${token}` },
})
return parseJsonOrThrow<ApiUserContext>(res, 'get user context')
}
export type PlannedDayType = 'sjukpenning' | 'lagsta' | 'vacation'
export interface DayAssertionPayload {
workspace_id: string
child_id: string
parent_personal_data_uuid: string
date: string
day_type: PlannedDayType
is_dubbeldag: boolean
}
// `/api/planned-days` is read-only (restructure step 3b) — every write goes
// through `POST /api/day-assertions` instead, which mirrors a concrete
// assertion straight into `planned_leave_day` (see
// `app/services/day_assertion_service.py`), so this still materializes a
// band the calendar renders immediately.
export async function apiAssertDay(token: string, payload: DayAssertionPayload): Promise<void> {
const res = await fetch(`${API_BASE}/api/day-assertions`, {
method: 'POST',
headers: { 'Content-Type': 'application/json', Authorization: `Bearer ${token}` },
body: JSON.stringify(payload),
})
if (!res.ok) {
throw new Error(`assert day ${payload.date} failed: ${res.status} ${await res.text()}`)
}
}
export interface ApiAge4Projection {
personal_data_uuid: string
savable_after_b4: number
expiring_at_b4: number
projected_left_at_b4: number
savable_cap_at_b4: number
}
export interface ApiWorkspaceOverview {
parent_projections: ApiAge4Projection[]
combined_expiring_at_b4: number
combined_days_left: number
}
export async function apiGetOverview(
token: string,
workspaceId: string,
childId: string,
): Promise<ApiWorkspaceOverview> {
const url = `${API_BASE}/api/analytics/${workspaceId}/overview?child_id=${childId}`
const res = await fetch(url, { headers: { Authorization: `Bearer ${token}` } })
return parseJsonOrThrow<ApiWorkspaceOverview>(res, 'get workspace overview')
}