Link planned days to their wish, fix the age-4 cap, drop the planning goal
Three changes that together unblock treating a calendar period as one editable object. Migration 008 adds `planned_leave_day.wish_id` (nullable, ON DELETE SET NULL) so a persisted day knows which `leave_wish` produced it, `is_pinned` to mark a day the user hand-edited, and `leave_wish.target_days` so a period drawn on a calendar need not be a whole number of weeks. Apply-time identity still keys on day_type/is_dubbeldag only, so a wish_id-only difference is a metadata update rather than a collision. The age-4 savable ceiling was applying the per-child figure of 96 to each parent's pool, modelling a two-parent family as able to save 192 days past the child's fourth birthday. `resolve_age4_savable_cap` is now the single place that decides 48 (couple with two parents) versus 96 (everyone else), and both AnalyticsService and the allocator read it. Migration 009 drops `workspace.planning_goal` and `leave_wish.goal_override`. The allocator's tier-3 policy collapses to one rule; `salary_type` still branches, since that reflects what a vacation day actually costs a parent rather than a user preference.
This commit is contained in:
@@ -263,8 +263,9 @@ def get_analytics_service(
|
||||
planned_repo: PlannedLeaveRepositoryDep,
|
||||
child_repo: ChildRepositoryDep,
|
||||
pd_repo: PersonalDataRepositoryDep,
|
||||
workspace_repo: WorkspaceRepositoryDep,
|
||||
) -> AnalyticsService:
|
||||
return AnalyticsService(leave_repo, planned_repo, child_repo, pd_repo)
|
||||
return AnalyticsService(leave_repo, planned_repo, child_repo, pd_repo, workspace_repo)
|
||||
|
||||
|
||||
AnalyticsServiceDep = Annotated[AnalyticsService, Depends(get_analytics_service)]
|
||||
|
||||
Reference in New Issue
Block a user