e2907db760
Three commits from mai/feynman/fristenrechner: -614f9affix(approval-pill): two-eyes glyph 👀 instead of single SVG eye on /deadlines + /appointments + /agenda. m's preference: emoji denotes "being looked at" closer to "wartet auf Genehmigung" semantics. -2d6ea3efeat(deadline-rules/is-optional): conditional rules opt-in via save modal. Adds paliad.deadline_rules.is_optional. Distinct from is_mandatory: a rule can be statutorily fixed when it applies AND conditional on whether it applies (RoP.151 cost-decision request, appeal-related deadlines). Save-modal pre-unchecks optional rows; user toggles to opt in. Timeline shows "auf Antrag" pill. -097e21cfeat(fristenrechner): proceeding-picker collapses to one-line "Verfahren: X · [Reselect]" pill after pick (saves vertical space). Column view becomes the default for the timeline (was previously whichever-default; m wants Column on first render). Migration housekeeping: feynman's migration was authored as 066 on his branch but main has already taken 066/067 via shannon's t-paliad-160 (approval policy split + drop required_role). Renumbered to 068 during merge to resolve the same-number collision. Added ADD COLUMN IF NOT EXISTS to make the up-migration idempotent (defensive for environments where the column was already applied out-of-band during dev). The RoP.151 backfill UPDATE is naturally idempotent. Live tracker bumped from 66 → 68 to reflect schema reality before this merge: shannon's 066+067 effects and feynman's is_optional column are all already present in the live youpc Supabase. The next deploy will see tracker=68 and have nothing to apply. Refs m/paliad#15, m/paliad#18 (rule-Typ contradiction filed against Item A scope, not part of this batch).
34 lines
1.5 KiB
SQL
34 lines
1.5 KiB
SQL
-- t-paliad-157 / m's 2026-05-08 batch Item 2: mark rules that are not
|
|
-- always part of every proceeding instance as optional. Examples m
|
|
-- named: Antrag auf Kostenentscheidung (RoP.151) — only fires when a
|
|
-- party files for it; some appeal-related deadlines that depend on
|
|
-- specific facts.
|
|
--
|
|
-- Distinct from is_mandatory: a rule can be is_mandatory=true (the
|
|
-- deadline is statutorily fixed when it applies) AND is_optional=true
|
|
-- (whether the deadline applies at all is a per-case choice). Default
|
|
-- false on backfill so the existing always-applies semantic stays.
|
|
--
|
|
-- Frontend reads is_optional and pre-unchecks the row in the save-
|
|
-- to-project modal; user toggles to opt in. Timeline view stays
|
|
-- unchanged — the rule still renders so the user sees what could
|
|
-- apply.
|
|
|
|
ALTER TABLE paliad.deadline_rules
|
|
ADD COLUMN IF NOT EXISTS is_optional boolean NOT NULL DEFAULT false;
|
|
|
|
COMMENT ON COLUMN paliad.deadline_rules.is_optional IS
|
|
'When true, the deadline is conditional on an act the user takes '
|
|
'(filing a cost-decision request, choosing to appeal, etc.) and '
|
|
'should be opt-in when saving to a project. Distinct from '
|
|
'is_mandatory, which is about statutory strictness once the rule '
|
|
'applies. Backfill: false on every existing row except a small '
|
|
'starter set m identified (RoP.151).';
|
|
|
|
-- Starter backfill: m's explicit example. More flips can land via
|
|
-- targeted UPDATEs as m reviews the rule library.
|
|
UPDATE paliad.deadline_rules
|
|
SET is_optional = true
|
|
WHERE rule_code = 'RoP.151'
|
|
AND is_active = true;
|