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

Fristenrechner cleanup: carry project through 'Add', drop 'Custom' from UPC proceeding label, remove 'Ich möchte etwas einreichen' option #57

New Issue
Open
opened 2026-05-20 12:04:27 +00:00 by mAi · 3 comments
mAi commented 2026-05-20 12:04:27 +00:00
Collaborator
Copy Link

Trigger

m 2026-05-20 14:02–14:04 on the Deadline Calculator (/tools/fristenrechner):

1. Pre-selected project gets lost on 'Add'

The Deadline Calculator needs an overhaul as well — when going through it, one can enter the project twice?! First in the beginning (I like!) but again when using the 'Add' functionality. There, the pre-selected project should be pre-selected...

At the start of the cascade m picks a project (good, scopes everything). When he later hits 'Add' (presumably to add a deadline to the project from a result row) the project picker comes up blank again. Should be pre-filled with the already-selected project. Override allowed but default carries forward.

2. 'Custom UPC Proceeding' label

it should not be 'Custom UPC Proceeding' — remove the 'custom'... it is a generic one, so no need to add anything there. Just list the types we have.

The proceeding-type picker (likely on the first step of the cascade or under 'add' flow) has an option labelled 'Custom UPC Proceeding'. m wants the 'Custom' prefix dropped — it's not custom, it's the generic UPC track. Just list the available types (upc.inf.cfi, upc.rev.cfi, upc.inf.cfi.ccr, etc.) under their actual names.

3. 'Ich möchte etwas einreichen' option out of scope

the Option then under 'Was ist passiert?' 'Ich möchte etwas einreichen' does not belong there... This is something else for a future workflow tool where we enter the whole decision tree from a different angle!

The Fristenrechner is a backward-looking calc — 'an event happened, now what deadlines spawn?'. The 'I want to file something' phrasing is forward-looking — 'I want to do X, what deadlines does my action trigger?'. Different mental model, different future tool. Remove the option from the 'Was ist passiert?' picker entirely; capture the idea elsewhere for the future-workflow tool.

What to do

  • (1) Fristenrechner 'Add' flow: pre-fill the project picker with the current cascade's project. Override allowed.
  • (2) Proceeding-type labels: strip 'Custom' prefix; render the type names cleanly. Audit other surfaces that may show 'Custom ' labels.
  • (3) Drop 'Ich möchte etwas einreichen' from the 'Was ist passiert?' picker. Track the future-workflow idea separately (see acceptance criteria — file a follow-up note).

Out of scope

  • Designing the future forward-workflow tool (separate task, larger scope).
  • Reshaping the broader cascade flow beyond the three items above.

Acceptance

  • Project pre-selected at start of cascade stays selected through 'Add'.
  • No 'Custom' prefix on UPC / DE / EPO proceeding-type labels in the Fristenrechner picker.
  • 'Was ist passiert?' picker no longer offers 'Ich möchte etwas einreichen'.
  • Filed follow-up note for the future forward-workflow tool (whichever surface m wants — issue stub, mBrian concept node, doc, whatever the project conventions support).

Role

coder direct — three focused UX cleanups in one surface. Group with other small UI items.

## Trigger m 2026-05-20 14:02–14:04 on the Deadline Calculator (`/tools/fristenrechner`): ### 1. Pre-selected project gets lost on 'Add' > The Deadline Calculator needs an overhaul as well — when going through it, one can enter the project twice?! First in the beginning (I like!) but again when using the 'Add' functionality. There, the pre-selected project should be pre-selected... At the start of the cascade m picks a project (good, scopes everything). When he later hits 'Add' (presumably to add a deadline to the project from a result row) the project picker comes up blank again. Should be **pre-filled** with the already-selected project. Override allowed but default carries forward. ### 2. 'Custom UPC Proceeding' label > it should not be 'Custom UPC Proceeding' — remove the 'custom'... it is a generic one, so no need to add anything there. Just list the types we have. The proceeding-type picker (likely on the first step of the cascade or under 'add' flow) has an option labelled 'Custom UPC Proceeding'. m wants the 'Custom' prefix dropped — it's not custom, it's the generic UPC track. Just list the available types (`upc.inf.cfi`, `upc.rev.cfi`, `upc.inf.cfi.ccr`, etc.) under their actual names. ### 3. 'Ich möchte etwas einreichen' option out of scope > the Option then under 'Was ist passiert?' 'Ich möchte etwas einreichen' does not belong there... This is something else for a future workflow tool where we enter the whole decision tree from a different angle! The Fristenrechner is a backward-looking calc — 'an event happened, now what deadlines spawn?'. The 'I want to file something' phrasing is forward-looking — 'I want to do X, what deadlines does my action trigger?'. Different mental model, different future tool. Remove the option from the 'Was ist passiert?' picker entirely; capture the idea elsewhere for the future-workflow tool. ## What to do - (1) Fristenrechner 'Add' flow: pre-fill the project picker with the current cascade's project. Override allowed. - (2) Proceeding-type labels: strip 'Custom' prefix; render the type names cleanly. Audit other surfaces that may show 'Custom <jurisdiction>' labels. - (3) Drop 'Ich möchte etwas einreichen' from the 'Was ist passiert?' picker. Track the future-workflow idea separately (see acceptance criteria — file a follow-up note). ## Out of scope - Designing the future forward-workflow tool (separate task, larger scope). - Reshaping the broader cascade flow beyond the three items above. ## Acceptance - Project pre-selected at start of cascade stays selected through 'Add'. - No 'Custom' prefix on UPC / DE / EPO proceeding-type labels in the Fristenrechner picker. - 'Was ist passiert?' picker no longer offers 'Ich möchte etwas einreichen'. - Filed follow-up note for the future forward-workflow tool (whichever surface m wants — issue stub, mBrian concept node, doc, whatever the project conventions support). ## Role **coder direct** — three focused UX cleanups in one surface. Group with other small UI items.
mAi self-assigned this 2026-05-20 12:04:27 +00:00
mAi commented 2026-05-20 12:05:18 +00:00
Author
Collaborator
Copy Link

4. Same-context-asked-twice bug

m 2026-05-20 14:04:

[example: picking 'Statement of Defence' / 'Klageerwiderung']

Statement of Defence
Klageerwiderung
Erwiderung des Beklagten auf eine Klageschrift…

In these proceedings:
  Infringement Action — Statement of Defence — UPC RoP R.23(1) — 3 months — Defendant
  Revocation Action — Defence to Revocation — UPC RoP R.49(1) — 3 months — Defendant
  Damages Determination — Defence to Application for Damages — UPC RoP R.137(2) — 2 months — Defendant
  Lay-open Books / Discovery — Defence — UPC RoP R.142(2) — 2 months — Defendant
  Provisional Measures — Response — 0 months — Defendant

× Which context?
  Infringement Action — Statement of Defence — UPC RoP R.23(1)
  Revocation Action — Defence to Revocation — UPC RoP R.49(1)
  Damages Determination — Defence to Application for Damages — UPC RoP R.137(2)
  Lay-open Books / Discovery — Defence — UPC RoP R.142(2)
  Provisional Measures — Response

It asks the same thing twice... that's not good. The context only should be asked once.

What's wrong

The Fristenrechner shows the event type's full per-proceeding context inline (the 'In these proceedings' list), then immediately asks the user 'Which context?' with the same five options. The information is presented and then re-asked as a question. Either show it as a picker from the start, or hide the list until a pick is needed — not both.

What to do

When the user lands on an event type that has multiple proceeding contexts:

  • If proceeding context is already known from the cascade (project → proceeding picked earlier, or proceeding-type filter applied), don't show the picker at all — auto-resolve to the known context.
  • If proceeding context is unknown, show the picker as the primary surface — the 'In these proceedings' summary block is redundant and confusing. Just the picker.

No × Which context? modal layered on top of an info block that already contained the same data.

Acceptance

  • Selecting Statement of Defence with proceeding context already set: result computed directly, no second picker.
  • Selecting Statement of Defence without proceeding context: a single picker (no preceding 'In these proceedings:' info block with the same rows).
  • Same fix applies to any other event type that has multiple proceeding contexts (R.23, R.29, R.46 Einspruch, etc.).
## 4. Same-context-asked-twice bug m 2026-05-20 14:04: > [example: picking 'Statement of Defence' / 'Klageerwiderung'] > > ``` > Statement of Defence > Klageerwiderung > Erwiderung des Beklagten auf eine Klageschrift… > > In these proceedings: > Infringement Action — Statement of Defence — UPC RoP R.23(1) — 3 months — Defendant > Revocation Action — Defence to Revocation — UPC RoP R.49(1) — 3 months — Defendant > Damages Determination — Defence to Application for Damages — UPC RoP R.137(2) — 2 months — Defendant > Lay-open Books / Discovery — Defence — UPC RoP R.142(2) — 2 months — Defendant > Provisional Measures — Response — 0 months — Defendant > > × Which context? > Infringement Action — Statement of Defence — UPC RoP R.23(1) > Revocation Action — Defence to Revocation — UPC RoP R.49(1) > Damages Determination — Defence to Application for Damages — UPC RoP R.137(2) > Lay-open Books / Discovery — Defence — UPC RoP R.142(2) > Provisional Measures — Response > ``` > > It asks the same thing twice... that's not good. The context only should be asked once. ### What's wrong The Fristenrechner shows the event type's full per-proceeding context inline (the 'In these proceedings' list), then immediately asks the user 'Which context?' with the same five options. The information is presented and then re-asked as a question. Either show it as a picker from the start, or hide the list until a pick is needed — not both. ### What to do When the user lands on an event type that has multiple proceeding contexts: - If proceeding context is **already known** from the cascade (project → proceeding picked earlier, or proceeding-type filter applied), don't show the picker at all — auto-resolve to the known context. - If proceeding context is **unknown**, show the picker as the primary surface — the 'In these proceedings' summary block is redundant and confusing. Just the picker. No `× Which context?` modal layered on top of an info block that already contained the same data. ### Acceptance - Selecting Statement of Defence with proceeding context already set: result computed directly, no second picker. - Selecting Statement of Defence without proceeding context: a single picker (no preceding 'In these proceedings:' info block with the same rows). - Same fix applies to any other event type that has multiple proceeding contexts (R.23, R.29, R.46 Einspruch, etc.).
mAi commented 2026-05-20 12:41:53 +00:00
Author
Collaborator
Copy Link

Fix in f6df857 — PR #66. Four parts:

  1. Add prefill — preselectedProjectId() helper drives both Pathway A Save modal + Pathway B card-calc 'Add' picker.
  2. 'Custom' prefix dropped — deadlines.step1.adhoc.{upc,de,epa,dpma} rewritten in DE + EN.
  3. Ich möchte etwas einreichen hidden via HIDDEN_CASCADE_ROOTS filter in loadEventCategoryTree(). Follow-up note filed at #65 for the future forward-workflow tool.
  4. Same-context-twice — pill-click → locked context caption (no second picker); card-body-click → picker is primary, rule pills section hidden via CSS while expanded. Cross-cutting trigger pills (Wiedereinsetzung etc.) preserved by design.

Not smoke-tested in a browser (sandbox has no Supabase auth env). Build + tests clean. Please verify on staging.

Fix in [f6df857](https://mgit.msbls.de/m/paliad/commit/f6df85758d50b8b6c84d7d92024e92eb45fcc9c1) — PR #66. Four parts: 1. **Add prefill** — `preselectedProjectId()` helper drives both Pathway A Save modal + Pathway B card-calc 'Add' picker. 2. **'Custom' prefix dropped** — `deadlines.step1.adhoc.{upc,de,epa,dpma}` rewritten in DE + EN. 3. **Ich möchte etwas einreichen hidden** via `HIDDEN_CASCADE_ROOTS` filter in `loadEventCategoryTree()`. Follow-up note filed at #65 for the future forward-workflow tool. 4. **Same-context-twice** — pill-click → locked context caption (no second picker); card-body-click → picker is primary, rule pills section hidden via CSS while expanded. Cross-cutting trigger pills (Wiedereinsetzung etc.) preserved by design. Not smoke-tested in a browser (sandbox has no Supabase auth env). Build + tests clean. Please verify on staging.
mAi commented 2026-05-20 12:44:49 +00:00
Author
Collaborator
Copy Link

Shipped via darwin on mai/darwin/* — merged into main; commit https://mgit.msbls.de/m/paliad/commit/f6df857. Live after next Dokploy deploy.

Shipped via darwin on `mai/darwin/*` — merged into main; commit https://mgit.msbls.de/m/paliad/commit/f6df857. Live after next Dokploy deploy.
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#57
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?