jacobh2
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
88 lines
3.5 KiB
Python
88 lines
3.5 KiB
Python
"""Abstract repository for PlannedLeaveDay calendar events."""
|
|
|
|
from abc import abstractmethod
|
|
from datetime import date
|
|
from uuid import UUID
|
|
|
|
from app.entities.planned_leave import PlannedLeaveDay
|
|
from app.repositories.base import Repository
|
|
|
|
|
|
class PlannedLeaveRepository(Repository[PlannedLeaveDay]):
|
|
@abstractmethod
|
|
async def list_by_workspace_child(
|
|
self,
|
|
workspace_id: UUID,
|
|
child_id: UUID,
|
|
from_date: date | None = None,
|
|
to_date: date | None = None,
|
|
) -> list[PlannedLeaveDay]:
|
|
"""Return planned days for a workspace+child, optionally within a date range."""
|
|
|
|
@abstractmethod
|
|
async def count_by_parent_type(
|
|
self,
|
|
personal_data_uuid: UUID,
|
|
child_id: UUID,
|
|
day_type: str,
|
|
from_date: date | None = None,
|
|
to_date: date | None = None,
|
|
) -> int:
|
|
"""Count planned days of a given type for a parent+child pair."""
|
|
|
|
@abstractmethod
|
|
async def count_dubbeldagar(self, child_id: UUID, from_date: date | None = None) -> int:
|
|
"""Count dubbeldagar already planned for a child (after from_date)."""
|
|
|
|
@abstractmethod
|
|
async def list_by_wish(self, wish_id: UUID) -> list[PlannedLeaveDay]:
|
|
"""Every row currently attributed to this wish.
|
|
|
|
`LeaveWishService.delete()` reads this BEFORE `delete_by_wish` to
|
|
learn each row's (workspace, child, parent, date) key, so it can
|
|
clear any `DayAssertion` sitting at that key too — once the rows
|
|
are gone there is nothing left to look their keys up from.
|
|
"""
|
|
|
|
@abstractmethod
|
|
async def delete_by_wish(self, wish_id: UUID) -> int:
|
|
"""Delete every row attributed to this wish (pinned or not) and return the count deleted.
|
|
|
|
See `LeaveWishService.delete()`: called before the `leave_wish` row is
|
|
removed so the FK's `ON DELETE SET NULL` never fires — by the time
|
|
that DELETE runs, no `planned_leave_day` row still references this
|
|
wish, so there is nothing left to orphan.
|
|
"""
|
|
|
|
@abstractmethod
|
|
async def create_many(self, items: list[PlannedLeaveDay]) -> None:
|
|
"""Bulk-insert rows in one round trip (`executemany`). Empty list is a no-op.
|
|
|
|
See backend-perf audit H1: a per-row `create()` + `commit()` loop
|
|
measured 88.7ms/300 rows (default journal mode); this + one
|
|
surrounding `unit_of_work()` is the batched replacement used by
|
|
`PlanningService.apply_proposed_days` stage 4.
|
|
"""
|
|
|
|
@abstractmethod
|
|
async def delete_many(self, ids: list[UUID]) -> int:
|
|
"""Delete rows by id in one or more `executemany`/`IN (...)` round trips.
|
|
|
|
Idempotent: an id with no matching row is silently ignored rather than
|
|
raising `NotFoundError` (unlike `delete()`) — callers that already
|
|
know some keys may have vanished (e.g. a re-applied batch) should not
|
|
have to pre-filter. Returns the number of rows actually deleted.
|
|
"""
|
|
|
|
@abstractmethod
|
|
async def update_metadata_many(self, pairs: list[tuple[UUID, UUID | None]]) -> None:
|
|
"""Bulk-update `wish_id` for existing rows via `executemany`.
|
|
|
|
Each pair is `(id, wish_id)`. Does not touch `day_type`/
|
|
`is_dubbeldag` — this is for the metadata-only path in
|
|
`apply_proposed_days` (a row whose type is unchanged but whose
|
|
`wish_id` differs from the incoming batch). `is_pinned` is not a
|
|
column on this entity any more (restructure step 3b, migration
|
|
010) — "pinned" is a `DayAssertion` fact now.
|
|
"""
|