m/paliad
1
0
Fork 0
Code Issues 151 Pull Requests 4 Actions Packages Projects Releases Wiki Activity

Browse-a-proceeding: side+appellant selectors + 'appealable decision' trigger label #81

New Issue
Open
opened 2026-05-25 11:23:34 +00:00 by mAi · 1 comment
mAi commented 2026-05-25 11:23:34 +00:00
Collaborator
Copy Link

m's report (2026-05-25 12:51 + 12:54)

In the "Browse a proceeding" feature I want to be able to select a side with some checkbox. We have it elsewhere already - and that will have to filter what deadlines show - currently there is an error with the appeal that starts with the trigger event "Appeal proceeding" but actually it would be the appealable decision. And then we should be able to select which party appeals so we dont have all these "both parties" entries in the timeline columns.

The goal is to have realistic timelines where we can filter between different perspectives and scenarios. Of course where we selected a proceeding, this will be automatic. So we need to include good parameters.

m pasted a worked example of the current state — every "both parties" deadline appears TWICE (once in Proactive, once in Reactive):

UPC Appeal Trigger date: Sat, 2026-05-23
  Proactive | Court | Reactive
  -----------+-------+-----------
  Notice of Appeal           Thu, 2026-07-23   UPC RoP R.220(1)   ↔ both parties
  Notice of Appeal           Thu, 2026-07-23   UPC RoP R.220(1)   ↔ both parties
  Statement of Grounds       Wed, 2026-09-23   UPC RoP R.220(1)   ↔ both parties
  Statement of Grounds       Wed, 2026-09-23   UPC RoP R.220(1)   ↔ both parties
  Response to Appeal         Mon, 2026-11-23                      ↔ both parties
  Response to Appeal         Mon, 2026-11-23                      ↔ both parties
  Cross-Appeal               Wed, 2026-12-23   UPC RoP R.237      ↔ both parties
  Cross-Appeal               Wed, 2026-12-23   UPC RoP R.237      ↔ both parties
  Reply to Cross-Appeal      Tue, 2027-02-23   UPC RoP R.238(1)   ↔ both parties
  Reply to Cross-Appeal      Tue, 2027-02-23   UPC RoP R.238(1)   ↔ both parties
  Oral Hearing               set by court
  Decision                   set by court

m: "This would be better then - thanks" — referring to the cleaned-up output once the appellant selector lands.

Scope

Three concerns, one task:

Concern A — Side / appellant selectors

  1. Add a side selector (checkbox or toggle group — reuse the component used elsewhere in paliad; find via grep -r for Klägerseite|Beklagtenseite|claimant|defendant checkboxes) to the Browse-a-proceeding page.
  2. When a side is selected, filter which deadlines render in the timeline columns — drop "both parties" duplicates by mapping each to the correct column (Proactive for the selected side; Reactive for the opposite side; or vice versa per existing semantics).
  3. Add an appellant selector for proceedings where one party initiates (Appeal, Counterclaim, Opposition, …). When set, "both parties" rows collapse to one row in the appellant's column.

Concern B — Appeal trigger label bug

The UPC Appeal proceeding currently uses trigger event "Appeal proceeding" but the actual trigger is the appealable decision (the first-instance ruling that starts the appeal clock). Rename / fix:

  • Look at paliad.event_types or wherever proceeding triggers live.
  • The user-visible label needs to be "Appealable Decision" / "Anfechtbare Entscheidung" (verify the correct DE legal term — likely "berufungsfähige Entscheidung" — coder verifies with m if uncertain).
  • The trigger_event slug / DB id stays stable (don't break links) but the label changes.

Concern C — Parameter contract for proceeding selection

When a project HAS a chosen proceeding (typical state), the side+appellant selectors should be auto-filled from the project's parties / counterclaim_of / submission history. The Browse-a-proceeding feature is the only place these are manual.

Define the parameter set cleanly:

  • side: claimant / defendant (or DE equivalent)
  • appellant: claimant / defendant / null (only relevant when proceeding has an appellant axis)
  • (Extensibility note: any further perspective axis goes here)

These flow into the deadline-rule resolution that builds the timeline columns.

What to do

  1. Find the Browse-a-proceeding UI (frontend/src/browse-proceeding.tsx or similar — verify path).
  2. Find the existing side-checkbox component used elsewhere — REUSE it; don't re-author.
  3. Wire the selectors into the URL query (?side=...&appellant=...) so the view is shareable.
  4. Update the timeline-column projection to consume the parameters and collapse/place "both parties" rows accordingly.
  5. Fix the UPC Appeal trigger label (Concern B). This is likely a one-line label change + i18n update.
  6. For projects with a real proceeding chosen, auto-fill the selectors from project context — read-only display, with an "override" toggle if useful.
  7. Add an integration test or service-level test for the column projection across at least one "both parties" rule and one party-specific rule.

Files most likely touched

  • frontend/src/browse-proceeding.tsx + corresponding client file
  • frontend/src/client/views/shape-timeline.ts (or whoever builds the column projection)
  • internal/services/projection_service.go — the column placement logic if it's server-side
  • DB seed / migration for the Appeal trigger label (read-only label change; do NOT change the slug)
  • i18n: new keys for side/appellant labels

Hard rules

  • Don't change deadline slugs / IDs — only labels.
  • The auto-fill from project context must be visible to the user (read-only display, not invisible state).
  • go build ./... && go test ./internal/... && cd frontend && bun run build clean.
  • Branch: mai/<worker>/proceeding-side-appellant.

Out of scope

  • Scenario-saving ("save this what-if as a named perspective").
  • Cross-project comparison.
  • New deadline rules — only their column placement / filtering.

Reporting

mai report completed with branch + SHAs + the UX path: open Browse-a-proceeding → pick UPC Appeal → choose appellant=claimant → confirm each deadline appears once in the correct column (no "both parties" duplicates) AND the trigger label reads "appealable decision" / equivalent.

## m's report (2026-05-25 12:51 + 12:54) > In the "Browse a proceeding" feature I want to be able to select a side with some checkbox. We have it elsewhere already - and that will have to filter what deadlines show - currently there is an error with the appeal that starts with the trigger event "Appeal proceeding" but actually it would be the appealable decision. And then we should be able to select which party appeals so we dont have all these "both parties" entries in the timeline columns. > > The goal is to have realistic timelines where we can filter between different perspectives and scenarios. Of course where we selected a proceeding, this will be automatic. So we need to include good parameters. m pasted a worked example of the current state — every "both parties" deadline appears TWICE (once in Proactive, once in Reactive): ``` UPC Appeal Trigger date: Sat, 2026-05-23 Proactive | Court | Reactive -----------+-------+----------- Notice of Appeal Thu, 2026-07-23 UPC RoP R.220(1) ↔ both parties Notice of Appeal Thu, 2026-07-23 UPC RoP R.220(1) ↔ both parties Statement of Grounds Wed, 2026-09-23 UPC RoP R.220(1) ↔ both parties Statement of Grounds Wed, 2026-09-23 UPC RoP R.220(1) ↔ both parties Response to Appeal Mon, 2026-11-23 ↔ both parties Response to Appeal Mon, 2026-11-23 ↔ both parties Cross-Appeal Wed, 2026-12-23 UPC RoP R.237 ↔ both parties Cross-Appeal Wed, 2026-12-23 UPC RoP R.237 ↔ both parties Reply to Cross-Appeal Tue, 2027-02-23 UPC RoP R.238(1) ↔ both parties Reply to Cross-Appeal Tue, 2027-02-23 UPC RoP R.238(1) ↔ both parties Oral Hearing set by court Decision set by court ``` m: "This would be better then - thanks" — referring to the cleaned-up output once the appellant selector lands. ## Scope Three concerns, one task: ### Concern A — Side / appellant selectors 1. Add a **side selector** (checkbox or toggle group — reuse the component used elsewhere in paliad; find via `grep -r` for `Klägerseite|Beklagtenseite|claimant|defendant` checkboxes) to the Browse-a-proceeding page. 2. When a side is selected, **filter** which deadlines render in the timeline columns — drop "both parties" duplicates by mapping each to the correct column (Proactive for the selected side; Reactive for the opposite side; or vice versa per existing semantics). 3. Add an **appellant selector** for proceedings where one party initiates (Appeal, Counterclaim, Opposition, …). When set, "both parties" rows collapse to one row in the appellant's column. ### Concern B — Appeal trigger label bug The UPC Appeal proceeding currently uses trigger event "Appeal proceeding" but the actual trigger is the **appealable decision** (the first-instance ruling that starts the appeal clock). Rename / fix: - Look at `paliad.event_types` or wherever proceeding triggers live. - The user-visible label needs to be "Appealable Decision" / "Anfechtbare Entscheidung" (verify the correct DE legal term — likely "berufungsfähige Entscheidung" — coder verifies with m if uncertain). - The trigger_event slug / DB id stays stable (don't break links) but the label changes. ### Concern C — Parameter contract for proceeding selection When a project HAS a chosen proceeding (typical state), the side+appellant selectors should be **auto-filled** from the project's parties / counterclaim_of / submission history. The Browse-a-proceeding feature is the only place these are manual. Define the parameter set cleanly: - `side`: claimant / defendant (or DE equivalent) - `appellant`: claimant / defendant / null (only relevant when proceeding has an appellant axis) - (Extensibility note: any further perspective axis goes here) These flow into the deadline-rule resolution that builds the timeline columns. ## What to do 1. Find the Browse-a-proceeding UI (`frontend/src/browse-proceeding.tsx` or similar — verify path). 2. Find the existing side-checkbox component used elsewhere — REUSE it; don't re-author. 3. Wire the selectors into the URL query (`?side=...&appellant=...`) so the view is shareable. 4. Update the timeline-column projection to consume the parameters and collapse/place "both parties" rows accordingly. 5. Fix the UPC Appeal trigger label (Concern B). This is likely a one-line label change + i18n update. 6. For projects with a real proceeding chosen, auto-fill the selectors from project context — read-only display, with an "override" toggle if useful. 7. Add an integration test or service-level test for the column projection across at least one "both parties" rule and one party-specific rule. ## Files most likely touched - `frontend/src/browse-proceeding.tsx` + corresponding client file - `frontend/src/client/views/shape-timeline.ts` (or whoever builds the column projection) - `internal/services/projection_service.go` — the column placement logic if it's server-side - DB seed / migration for the Appeal trigger label (read-only label change; do NOT change the slug) - i18n: new keys for side/appellant labels ## Hard rules - Don't change deadline slugs / IDs — only labels. - The auto-fill from project context must be visible to the user (read-only display, not invisible state). - `go build ./... && go test ./internal/... && cd frontend && bun run build` clean. - Branch: `mai/<worker>/proceeding-side-appellant`. ## Out of scope - Scenario-saving ("save this what-if as a named perspective"). - Cross-project comparison. - New deadline rules — only their column placement / filtering. ## Reporting `mai report completed` with branch + SHAs + the UX path: open Browse-a-proceeding → pick UPC Appeal → choose appellant=claimant → confirm each deadline appears once in the correct column (no "both parties" duplicates) AND the trigger label reads "appealable decision" / equivalent.
mAi self-assigned this 2026-05-25 11:23:34 +00:00
mAi commented 2026-05-25 11:58:34 +00:00
Author
Collaborator
Copy Link

Done — branch mai/hermes/gitster-browse-a

Commit: 02255c4234

What changed

Concern A — side + appellant selectors on /tools/verfahrensablauf

Added a perspective strip below the trigger-date row in step 2:

  • Seite: — Klägerseite / Beklagtenseite / Beide (default Beide). Side=defendant swaps the column labels so the user's own side is the Proaktiv column ("your filings") and the opposing side is Reaktiv.
  • Berufung durch: — Klägerseite / Beklagtenseite / — (default —). When set, party='both' rows collapse to a single row in the appellant's column — no more duplicate "both parties" entries across Proactive + Reactive.

Both selectors are URL-driven (?side=…&appellant=…) so the perspective survives reload and is shareable. The appellant row hides itself for proceedings without an appellant axis (first-instance Inf / Rev / Opp) via a small allowlist.

Concern B — UPC Appeal trigger label

"Auslösendes Ereignis" on /tools/verfahrensablauf now reads Anfechtbare Entscheidung / Appealable Decision instead of falling back to "Berufungsverfahren" / "Appeal". Implemented as an optional trigger_event_label_{de,en} column on paliad.proceeding_types (mig 121); the frontend prefers it over the proceedingName fallback that fires when no rule has IsRootEvent=true. No deadline-rule additions, no slug changes — hard rule from the issue.

Concern C — parameter contract

Column routing extracted into bucketDeadlinesIntoColumns(deadlines, {side, appellant}) — a pure helper that renderColumnsBody now calls. The selectors are auto-populatable from project context in the future (when /tools/verfahrensablauf gains an Akte binding) — for now the wizard is no-project, so only manual selection.

Files

  • internal/db/migrations/121_proceeding_trigger_event_label.{up,down}.sql — schema + UPC Appeal label seed
  • internal/models/models.go — ProceedingType.TriggerEventLabel{DE,EN}
  • internal/services/fristenrechner.go — UIResponse exposes triggerEventLabel{,EN}
  • frontend/src/verfahrensablauf.tsx — perspective strip in step 2
  • frontend/src/client/verfahrensablauf.ts — ?side + ?appellant URL state, recalc-free re-render, appellant-axis allowlist (upc.apl.*, DE Berufung/Revision, dpma.appeal.*, epa.opp.boa)
  • frontend/src/client/views/verfahrensablauf-core.ts — bucketDeadlinesIntoColumns helper + column-label swap
  • frontend/src/client/views/verfahrensablauf-core.test.ts — 7 new tests pinning the routing matrix
  • frontend/src/client/i18n.ts, frontend/src/i18n-keys.ts — new DE/EN strings
  • frontend/src/styles/global.css — .verfahrensablauf-perspective layout

Verification

  • go build ./... clean
  • go test ./... all green
  • bun run build (frontend) clean
  • bun test 110/110 (12 new + 98 prior)
  • Migration 121 applied to paliad schema; UPC Appeal carries the curated trigger label

UX path (once deployed)

  1. Open /tools/verfahrensablauf
  2. Pick UPC → Berufung
  3. "Auslösendes Ereignis" now reads Anfechtbare Entscheidung (DE) / Appealable Decision (EN) ✔
  4. Pick Berufung durch: Klägerseite — Notice of Appeal, Statement of Grounds, Response to Appeal, Cross-Appeal, Reply to Cross-Appeal each appear ONCE in the Proactive column (no more duplicates).
  5. Flip to Berufung durch: Beklagtenseite — same rows now appear ONCE in the Reactive column.
  6. URL carries ?side=…&appellant=… for share/reload.

Out of scope (filed-as-future)

The current spec collapses ALL party='both' rules into the appellant's column. Strictly speaking some of them (Response to Appeal, Cross-Appeal) are respondent-side filings — but the deadline_rules schema doesn't carry per-rule appellant/respondent tagging yet, and the issue's hard rules excluded schema additions. Filing as follow-up: enrich paliad.deadline_rules with an appellant_role: 'appellant' | 'respondent' | null column so respondent filings land in the respondent's column instead. That would turn the current single-column collapse into the realistic-per-row routing m's original brief alludes to.

## Done — branch `mai/hermes/gitster-browse-a` Commit: https://mgit.msbls.de/m/paliad/commit/02255c42344e4c3a2caba262a5381431a1b5d0ed ### What changed **Concern A — side + appellant selectors on /tools/verfahrensablauf** Added a perspective strip below the trigger-date row in step 2: - `Seite:` — Klägerseite / Beklagtenseite / Beide (default Beide). Side=defendant swaps the column labels so the user's own side is the **Proaktiv** column ("your filings") and the opposing side is **Reaktiv**. - `Berufung durch:` — Klägerseite / Beklagtenseite / — (default —). When set, `party='both'` rows collapse to a **single row in the appellant's column** — no more duplicate "both parties" entries across Proactive + Reactive. Both selectors are URL-driven (`?side=…&appellant=…`) so the perspective survives reload and is shareable. The appellant row hides itself for proceedings without an appellant axis (first-instance Inf / Rev / Opp) via a small allowlist. **Concern B — UPC Appeal trigger label** "Auslösendes Ereignis" on /tools/verfahrensablauf now reads **Anfechtbare Entscheidung** / **Appealable Decision** instead of falling back to "Berufungsverfahren" / "Appeal". Implemented as an optional `trigger_event_label_{de,en}` column on `paliad.proceeding_types` (mig 121); the frontend prefers it over the proceedingName fallback that fires when no rule has `IsRootEvent=true`. **No deadline-rule additions, no slug changes** — hard rule from the issue. **Concern C — parameter contract** Column routing extracted into `bucketDeadlinesIntoColumns(deadlines, {side, appellant})` — a pure helper that `renderColumnsBody` now calls. The selectors are auto-populatable from project context in the future (when /tools/verfahrensablauf gains an Akte binding) — for now the wizard is no-project, so only manual selection. ### Files - `internal/db/migrations/121_proceeding_trigger_event_label.{up,down}.sql` — schema + UPC Appeal label seed - `internal/models/models.go` — `ProceedingType.TriggerEventLabel{DE,EN}` - `internal/services/fristenrechner.go` — UIResponse exposes `triggerEventLabel{,EN}` - `frontend/src/verfahrensablauf.tsx` — perspective strip in step 2 - `frontend/src/client/verfahrensablauf.ts` — `?side` + `?appellant` URL state, recalc-free re-render, appellant-axis allowlist (`upc.apl.*`, DE Berufung/Revision, `dpma.appeal.*`, `epa.opp.boa`) - `frontend/src/client/views/verfahrensablauf-core.ts` — `bucketDeadlinesIntoColumns` helper + column-label swap - `frontend/src/client/views/verfahrensablauf-core.test.ts` — 7 new tests pinning the routing matrix - `frontend/src/client/i18n.ts`, `frontend/src/i18n-keys.ts` — new DE/EN strings - `frontend/src/styles/global.css` — `.verfahrensablauf-perspective` layout ### Verification - `go build ./...` clean - `go test ./...` all green - `bun run build` (frontend) clean - `bun test` 110/110 (12 new + 98 prior) - Migration 121 applied to paliad schema; UPC Appeal carries the curated trigger label ### UX path (once deployed) 1. Open `/tools/verfahrensablauf` 2. Pick UPC → Berufung 3. "Auslösendes Ereignis" now reads `Anfechtbare Entscheidung` (DE) / `Appealable Decision` (EN) ✔ 4. Pick `Berufung durch: Klägerseite` — Notice of Appeal, Statement of Grounds, Response to Appeal, Cross-Appeal, Reply to Cross-Appeal each appear ONCE in the Proactive column (no more duplicates). 5. Flip to `Berufung durch: Beklagtenseite` — same rows now appear ONCE in the Reactive column. 6. URL carries `?side=…&appellant=…` for share/reload. ### Out of scope (filed-as-future) The current spec collapses ALL `party='both'` rules into the appellant's column. Strictly speaking some of them (Response to Appeal, Cross-Appeal) are **respondent-side** filings — but the deadline_rules schema doesn't carry per-rule appellant/respondent tagging yet, and the issue's hard rules excluded schema additions. Filing as follow-up: enrich `paliad.deadline_rules` with an `appellant_role: 'appellant' | 'respondent' | null` column so respondent filings land in the respondent's column instead. That would turn the current single-column collapse into the realistic-per-row routing m's original brief alludes to.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
deferred
Parked — not pursuing now, may un-park later
done
Work completed by an agent; awaiting m to close
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
mAi m
No Assignees mAi
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/paliad#81
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?