Track preschool planning days, partner invites and real vacation forfeiture

Three strands of work that grew together across the same settings screen and API client, so they land as one change. Per-year preschool planning days ("studiedagar"): new table, repository (SQLite + Postgres), service, router and migration 007, plus the hooks and Settings UI to plan and record them per child and year. Allocation now reserves the recorded figure for a year where one exists and only falls back to the child-level estimate otherwise, marking that fallback as assumed. Partner invitations: workspaces issue and list invitations, registration accepts an invite token to join the inviter's workspace instead of creating a personal one, and a /join/:token page plus the settings invite panel drive it. Vacation forfeiture: tips and the dashboard now distinguish days a parent genuinely loses from days that merely age, so the warning stops firing on balances that were never at risk. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-20 11:22:07 +02:00
parent 6904961bb4
commit 0e9b20ec37
88 changed files with 5301 additions and 348 deletions
@@ -0,0 +1,67 @@
+"""Add preschool_planning_days: per-year record of "studiedagar" taken.
+
+`Child.preschool_planning_days_per_year` (see `app/entities/child.py`) is a
+single default count of annual preschool closure/planning days used by
+`app/services/allocation_service.py::_preschool_reserve_days`, which
+multiplies it by the number of years in the planning horizon and subtracts
+the lump sum from both parents' parental-leave pools. There was never a
+per-year record of the true count, nor of how many were actually taken.
+
+This table adds that per-year record: `planned_days` (may differ from the
+child's default for a specific year) and `taken_days` (nullable — `NULL`
+means "not recorded yet", distinct from "recorded as zero", which is the
+whole point of the feature). A missing row for a (child, year) still falls
+back to `child.preschool_planning_days_per_year` at the service layer (see
+`app/services/preschool_planning_days_service.py`); wiring the allocation
+engine to consume these rows is a follow-up, not part of this migration.
+
+A plain `CREATE TABLE` suffices — nothing existing changes, and there is
+nothing to backfill: before this migration no per-year figure could be
+recorded, so the correct history is "none".
+
+Must stay byte-for-byte equivalent to the `preschool_planning_days` table in
+`app/db/connection.py`'s `_FULL_SCHEMA` —
+`tests/integration/test_schema_parity.py` asserts exactly that.
+
+Revision ID: 007
+Revises: 006
+Create Date: 2026-09-20
+"""
+
+from __future__ import annotations
+
+from alembic import op
+
+revision: str = "007"
+down_revision: str | None = "006"
+branch_labels: str | None = None
+depends_on: str | None = None
+
+
+def upgrade() -> None:
+    op.execute(
+        """
+        CREATE TABLE IF NOT EXISTS preschool_planning_days (
+            id TEXT PRIMARY KEY,
+            child_id TEXT NOT NULL,
+            year INTEGER NOT NULL,
+            planned_days INTEGER NOT NULL,
+            taken_days INTEGER,
+            created_at TIMESTAMP NOT NULL,
+            updated_at TIMESTAMP NOT NULL,
+            UNIQUE(child_id, year),
+            FOREIGN KEY (child_id) REFERENCES child(id) ON DELETE CASCADE
+        )
+        """
+    )
+    op.execute(
+        """
+        CREATE INDEX IF NOT EXISTS idx_preschool_planning_days_child
+            ON preschool_planning_days (child_id)
+        """
+    )
+
+
+def downgrade() -> None:
+    op.execute("DROP INDEX IF EXISTS idx_preschool_planning_days_child")
+    op.execute("DROP TABLE IF EXISTS preschool_planning_days")