Rework balances around per-parent days left and deduce the partner from FK

Manual entry now takes one parent's sjukpenningnivå, lägstanivå and
dubbeldagar left (plus optional reserved days) and derives the rest in
build_snapshot, shared with the scraper. The scraper also reads the
family panel and exposes a partner deduction; with two parents it is
saved as a 'deduced' snapshot (migration 002). Parent count is the single
source of entitlement: one member gets 480 days and 96 savable at age 4,
two get 240 and 48 each. Workspaces are capped at two parents.

Also lands the in-flight squash of migrations 002–011 into the initial
schema and the removal of planning_mode.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
2026-09-19 12:27:29 +02:00
parent 375bc64f2f
commit e4719cb9ae
71 changed files with 5705 additions and 1859 deletions
+12
View File
@@ -46,6 +46,10 @@ class LeaveWishCreate(BaseModel):
# bounding range the allocator searches within for the best-costing window.
window_mode: str = "fixed" # 'fixed' | 'flexible'
# §Decision A (co-leave) — opt-in dubbeldagar; see app/entities/leave_wish.py.
# Only meaningful when parent_mode == 'both'.
wants_dubbeldag: bool = False
class LeaveWishUpdate(BaseModel):
"""Partial update — all fields optional; only provided fields are changed."""
@@ -78,6 +82,11 @@ class LeaveWishUpdate(BaseModel):
window_mode: str | None = None # 'fixed' | 'flexible'
# `None` means "leave unchanged" here too, same as every other field on
# this partial-update model -- there is no "clear it back to False" need
# (False is already the shape-level default), so no `_clear_*` flag.
wants_dubbeldag: bool | None = None
class LeaveWishResponse(BaseModel):
id: UUID
@@ -103,6 +112,8 @@ class LeaveWishResponse(BaseModel):
window_mode: str
wants_dubbeldag: bool
created_at: datetime | None
updated_at: datetime | None
@@ -127,6 +138,7 @@ class LeaveWishResponse(BaseModel):
parent_mode=entity.parent_mode,
parent_personal_data_uuid=entity.parent_personal_data_uuid,
window_mode=entity.window_mode,
wants_dubbeldag=entity.wants_dubbeldag,
created_at=entity.created_at,
updated_at=entity.updated_at,
)
+17 -10
View File
@@ -1,6 +1,7 @@
"""Pydantic schemas for parental leave fetch endpoints."""
from datetime import datetime
from typing import Literal
from uuid import UUID
from pydantic import BaseModel, Field
@@ -29,19 +30,25 @@ class TierDataResponse(BaseModel):
class ManualFetchRequest(BaseModel):
"""Per-parent "days left" manual entry — everything else (tier totals,
days used, reserved/transferable split) is derived by the same shared
function the FK scraper uses (`app.services.leave_snapshot.build_snapshot`),
so a manually-entered snapshot and a scraped one can never disagree on
how the numbers are derived.
"""
personal_data_uuid: UUID
workspace_id: UUID
child_id: UUID
total_days: int = Field(ge=0, le=480)
days_used: int = Field(ge=0, le=480)
reserved_days_total: int = Field(default=90, ge=0, le=240)
reserved_days_left: int = Field(ge=0, le=240)
transferable_days_left: int = Field(ge=0, le=150)
dubbeldagar_left: int = Field(default=60, ge=0, le=60)
sjukpenning_total: int = Field(default=390, ge=0, le=390)
sjukpenning_used: int = Field(ge=0, le=390)
lagsta_niva_total: int = Field(default=90, ge=0, le=90)
lagsta_niva_used: int = Field(ge=0, le=90)
sjukpenning_left: int = Field(ge=0, le=390)
lagsta_niva_left: int = Field(ge=0, le=90)
dubbeldagar_left: int = Field(ge=0, le=60)
# None -> derived from the transferable-first assumption in `build_snapshot`.
reserved_days_left: int | None = Field(default=None, ge=0, le=90)
# None -> defaults to `rules.total_days_per_child // parent_count`
# (480 solo, 240 with a partner) — see `ManualFetchService.save_manual_entry`.
total_days: int | None = Field(default=None, ge=0, le=480)
source: Literal["manual", "deduced"] = "manual"
class ParentalLeaveFetchResponse(BaseModel):
+105
View File
@@ -11,6 +11,7 @@ for the idempotency/collision/`replace` semantics.
"""
from datetime import date
from typing import Literal
from uuid import UUID
from pydantic import BaseModel, Field
@@ -19,13 +20,22 @@ from app.models.planned_leave import PlannedLeaveDayResponse
from app.services.allocation_service import PlanProposal
from app.services.planning_service import (
DayCollision,
EvictionCandidate,
EvictionPreview,
PlanApplyResult,
PlanChange,
PlanSyncResult,
ProposedDayInput,
Rejection,
ResourceShortage,
)
# Wire-level mirror of `PlanningService`'s `EVICTION_CHOICE_*` constants —
# kept as a `Literal` here (rather than importing the string constants) so
# an invalid value 422s at the Pydantic boundary instead of silently
# reaching the service as a no-op "do nothing".
EvictionChoice = Literal["drop_future_pl", "drop_latest_vacation_this_year"]
class PlanProposeRequest(BaseModel):
workspace_id: UUID
@@ -77,6 +87,9 @@ class WindowOutcomeResponse(BaseModel):
weeks_funded: float
shortfall_days: int
strategy: str
requested_strategy: str
strategy_degraded: bool
dubbeldagar_legally_available: bool
message_key: str
data: dict[str, object]
cost_breakdown: dict[str, int]
@@ -164,6 +177,9 @@ class PlanProposalResponse(BaseModel):
weeks_funded=o.weeks_funded,
shortfall_days=o.shortfall_days,
strategy=o.strategy,
requested_strategy=o.requested_strategy,
strategy_degraded=o.strategy_degraded,
dubbeldagar_legally_available=o.dubbeldagar_legally_available,
message_key=o.message_key,
data=o.data,
cost_breakdown=o.cost_breakdown,
@@ -341,6 +357,15 @@ class PlanApplyResponse(BaseModel):
class PlanSyncRequest(BaseModel):
workspace_id: UUID
# Which of the three user-facing options resolves a would-evict save
# (§ eviction preview). Omitted/`None` — the default — means "do
# nothing": the save is refused and nothing is mutated, exactly as if
# the user picked the explicit cancel option. Only meaningful when the
# response's `eviction_preview.would_evict` was `True` on a prior call
# with the same edit already persisted upstream (e.g. via the leave-wish
# endpoints) — a plain sync that fits within budget ignores this field
# entirely (never asked for a choice in the first place).
eviction_choice: EvictionChoice | None = None
class PlanChangeResponse(BaseModel):
@@ -378,10 +403,89 @@ class PlanChangeResponse(BaseModel):
)
class EvictionCandidateResponse(BaseModel):
"""One previously-persisted day a fresh sync would otherwise silently
delete — see `EvictionCandidate`'s docstring. `wish_name` is `None` when
the owning wish's name couldn't be resolved (never a reason to hide the
day itself).
"""
date: date
parent_personal_data_uuid: UUID
child_id: UUID
day_type: str
is_dubbeldag: bool
wish_id: UUID
wish_name: str | None
@classmethod
def from_domain(cls, candidate: EvictionCandidate) -> "EvictionCandidateResponse":
return cls(
date=candidate.date,
parent_personal_data_uuid=candidate.parent_personal_data_uuid,
child_id=candidate.child_id,
day_type=candidate.day_type,
is_dubbeldag=candidate.is_dubbeldag,
wish_id=candidate.wish_id,
wish_name=candidate.wish_name,
)
class ResourceShortageResponse(BaseModel):
"""One exhausted resource behind an eviction preview — see
`ResourceShortage`'s docstring. `resource_kind == 'parental_leave'`
carries `tier`/`child_id` (`year` is `None`); `resource_kind ==
'vacation'` carries `year` instead (`tier`/`child_id` are `None`).
Structured on purpose — the frontend composes the warning text itself,
never a backend-rendered string.
"""
resource_kind: str
parent_personal_data_uuid: UUID
tier: str | None
child_id: UUID | None
year: int | None
days_evicted: int
@classmethod
def from_domain(cls, shortage: ResourceShortage) -> "ResourceShortageResponse":
return cls(
resource_kind=shortage.resource_kind,
parent_personal_data_uuid=shortage.parent_personal_data_uuid,
tier=shortage.tier,
child_id=shortage.child_id,
year=shortage.year,
days_evicted=shortage.days_evicted,
)
class EvictionPreviewResponse(BaseModel):
"""Always present on `PlanSyncResponse`; `would_evict: false` with empty
lists in the common (fits-within-budget) case — see
`EvictionPreview`'s docstring.
"""
would_evict: bool
candidates: list[EvictionCandidateResponse]
shortages: list[ResourceShortageResponse]
@classmethod
def from_domain(cls, preview: EvictionPreview) -> "EvictionPreviewResponse":
return cls(
would_evict=preview.would_evict,
candidates=[EvictionCandidateResponse.from_domain(c) for c in preview.candidates],
shortages=[ResourceShortageResponse.from_domain(s) for s in preview.shortages],
)
class PlanSyncResponse(BaseModel):
proposal: PlanProposalResponse
apply_result: PlanApplyResponse
changes: list[PlanChangeResponse]
eviction_preview: EvictionPreviewResponse
@classmethod
def from_domain(cls, result: PlanSyncResult) -> "PlanSyncResponse":
@@ -389,4 +493,5 @@ class PlanSyncResponse(BaseModel):
proposal=PlanProposalResponse.from_domain(result.proposal),
apply_result=PlanApplyResponse.from_domain(result.apply_result),
changes=[PlanChangeResponse.from_domain(c) for c in result.changes],
eviction_preview=EvictionPreviewResponse.from_domain(result.eviction_preview),
)
-3
View File
@@ -15,13 +15,11 @@ class WorkspaceCreate(BaseModel):
class WorkspaceUpdate(BaseModel):
name: str | None = Field(default=None, min_length=1, max_length=100)
planning_mode: str | None = None
class WorkspaceResponse(BaseModel):
id: UUID
name: str
planning_mode: str
created_at: datetime | None
@classmethod
@@ -29,7 +27,6 @@ class WorkspaceResponse(BaseModel):
return cls(
id=ws.id,
name=ws.name,
planning_mode=ws.planning_mode,
created_at=ws.created_at,
)