782415122d
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
104 lines
3.9 KiB
TypeScript
104 lines
3.9 KiB
TypeScript
/**
|
|
* Runs once before the whole E2E suite. Two jobs:
|
|
*
|
|
* 1. Seed a known-good demo workspace deterministically, by shelling out to
|
|
* the same `backend/scripts/seed_demo.py --reset` a human would run —
|
|
* see that script's docstring for exactly what it creates (couple
|
|
* workspace, Alex/Sam/Nova, wishes, overrides, a few applied days).
|
|
*
|
|
* 2. Materialize one extra, deterministic multi-week band of planned leave
|
|
* days via the API (never by clicking through the UI) — the calendar
|
|
* only renders committed `planned_leave_day` rows, not raw wishes, and
|
|
* the seed script's own applied days are only 3 days long (too short to
|
|
* exercise cross-week-row banding). The band's dates are computed
|
|
* relative to "today", never hardcoded, and written to
|
|
* `e2e/.auth/fixture.json` for `calendar-band.spec.ts` to read.
|
|
*
|
|
* Defensive design: this polls the backend's health endpoint before doing
|
|
* anything else, regardless of what order Playwright happens to start
|
|
* `webServer` vs. `globalSetup` in — a setup failure here should always be
|
|
* "the backend never came up", never a flaky race.
|
|
*/
|
|
import { mkdirSync, writeFileSync } from 'node:fs'
|
|
import path from 'node:path'
|
|
import { execFileSync } from 'node:child_process'
|
|
import { fileURLToPath } from 'node:url'
|
|
import { apiAssertDay, apiGetContext, apiLogin, DEMO_EMAIL, DEMO_PASSWORD, waitForBackendHealth } from './support/api'
|
|
import { FIXTURE_PATH } from './support/fixture'
|
|
|
|
const __dirname = path.dirname(fileURLToPath(import.meta.url))
|
|
const BACKEND_DIR = path.resolve(__dirname, '../../backend')
|
|
|
|
// A deterministic multi-week band, independent of the leave-wish allocation
|
|
// engine's own date choices: 15 consecutive WEEKDAYS (~3 calendar-week
|
|
// rows), starting on the 1st of the month that is two months after
|
|
// "today" — always safely in the future, always entirely inside one
|
|
// calendar month (so the Calendar page shows both the band's true start and
|
|
// true end in a single month view), and never tied to a hardcoded year.
|
|
function computeBandDates(): { startDate: string; endDate: string; dates: string[] } {
|
|
const now = new Date()
|
|
const monthStart = new Date(Date.UTC(now.getUTCFullYear(), now.getUTCMonth() + 2, 1))
|
|
const dates: string[] = []
|
|
const cursor = new Date(monthStart.getTime())
|
|
while (dates.length < 15) {
|
|
const weekday = cursor.getUTCDay()
|
|
if (weekday !== 0 && weekday !== 6) {
|
|
dates.push(cursor.toISOString().slice(0, 10))
|
|
}
|
|
cursor.setUTCDate(cursor.getUTCDate() + 1)
|
|
}
|
|
const first = dates[0]
|
|
const last = dates[dates.length - 1]
|
|
if (!first || !last) throw new Error('failed to compute band dates')
|
|
return { startDate: first, endDate: last, dates }
|
|
}
|
|
|
|
export default async function globalSetup(): Promise<void> {
|
|
await waitForBackendHealth()
|
|
|
|
execFileSync('uv', ['run', 'python', 'scripts/seed_demo.py', '--reset'], {
|
|
cwd: BACKEND_DIR,
|
|
stdio: 'inherit',
|
|
})
|
|
|
|
const token = await apiLogin(DEMO_EMAIL, DEMO_PASSWORD)
|
|
const context = await apiGetContext(token)
|
|
const child = context.children[0]
|
|
if (!child) {
|
|
throw new Error('seed_demo.py did not create a child for the demo workspace')
|
|
}
|
|
|
|
const band = computeBandDates()
|
|
for (const date of band.dates) {
|
|
await apiAssertDay(token, {
|
|
workspace_id: context.workspace_id,
|
|
child_id: child.id,
|
|
parent_personal_data_uuid: context.personal_data_uuid,
|
|
date,
|
|
day_type: 'vacation',
|
|
is_dubbeldag: false,
|
|
})
|
|
}
|
|
|
|
mkdirSync(path.dirname(FIXTURE_PATH), { recursive: true })
|
|
writeFileSync(
|
|
FIXTURE_PATH,
|
|
JSON.stringify(
|
|
{
|
|
workspaceId: context.workspace_id,
|
|
childId: child.id,
|
|
personalDataUuid: context.personal_data_uuid,
|
|
childBirthDate: child.birth_date,
|
|
band: {
|
|
startDate: band.startDate,
|
|
endDate: band.endDate,
|
|
parentPersonalDataUuid: context.personal_data_uuid,
|
|
dayType: 'vacation',
|
|
},
|
|
},
|
|
null,
|
|
2,
|
|
),
|
|
)
|
|
}
|