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

Deadlines editor: reorder fields — event type comes before rule (rule is a child of event type, render together) #56

New Issue
Open
opened 2026-05-20 12:01:15 +00:00 by mAi · 1 comment
mAi commented 2026-05-20 12:01:15 +00:00
Collaborator
Copy Link

Trigger

m 2026-05-20 14:00:

In the deadlines editor the fields order seems wrong. It is Title, then rule, then event type. But actually the Rule is closely related to the event type and should — if at all — be displayed after it and together with it (like: Preliminary Objection — RoP.019 or something like that).

Current state (verify in design)

Deadlines edit/create form (likely frontend/src/deadlines-new.tsx + frontend/src/deadlines-detail.tsx + the editable-fields used by the unified-modal approval-edit-modal.ts) renders fields in this order:

  1. Title
  2. Rule (rule_code, RoP.* / DE.ZPO.* etc.)
  3. Event type (proceeding-event-type from the catalog)

Logically the event type is the parent concept — it identifies the procedural step ('Preliminary Objection', 'Klageerwiderung'). The rule is the citation under that event type — RoP.019 is the rule that defines Preliminary Objection.

What to do

  • Reorder: Title → Event Type → Rule.
  • Better: render Rule together with Event Type as a compound display, e.g. 'Preliminary Objection — RoP.019' or 'Klageerwiderung — DE.ZPO.276 III'. The rule is meta on the event type, not a peer field.
  • Form-level: keep separate inputs for selection (event type picker + rule picker still distinct, since some rules attach to multiple event types and vice versa) but visually group them in one labelled block with the rule rendered as a chip / hint under the event type select.
  • Same treatment applies to read-only display surfaces (deadline detail page, approval-edit-modal read-only context section, project Verlauf timeline entries).

Open design calls

  1. Compound rendering shape — 'Event Type — Rule' (dash) vs 'Event Type (Rule)' (parens) vs Event Type on top + Rule as subtitle.
  2. Empty-rule handling — when only event type is set, render the event type alone (no trailing dash).
  3. Empty-event-type handling — when only rule is set, render the rule alone (rare; transitional state).

Out of scope

  • Reshaping the proceeding-event-types catalog.
  • Changing the rule citation format inside the rule itself.
  • Cascading the same compound rendering to other entity types beyond deadlines.

Role

coder direct — visual reorder + compound rendering helper + i18n. Group with other small UI items.

## Trigger m 2026-05-20 14:00: > In the deadlines editor the fields order seems wrong. It is Title, then rule, then event type. But actually the Rule is closely related to the event type and should — if at all — be displayed after it and together with it (like: Preliminary Objection — RoP.019 or something like that). ## Current state (verify in design) Deadlines edit/create form (likely `frontend/src/deadlines-new.tsx` + `frontend/src/deadlines-detail.tsx` + the editable-fields used by the unified-modal `approval-edit-modal.ts`) renders fields in this order: 1. Title 2. Rule (rule_code, RoP.* / DE.ZPO.* etc.) 3. Event type (proceeding-event-type from the catalog) Logically the **event type is the parent concept** — it identifies the procedural step ('Preliminary Objection', 'Klageerwiderung'). The **rule is the citation** under that event type — `RoP.019` is the rule that defines Preliminary Objection. ## What to do - Reorder: Title → Event Type → Rule. - Better: **render Rule together with Event Type** as a compound display, e.g. 'Preliminary Objection — RoP.019' or 'Klageerwiderung — DE.ZPO.276 III'. The rule is meta on the event type, not a peer field. - Form-level: keep separate inputs for selection (event type picker + rule picker still distinct, since some rules attach to multiple event types and vice versa) but visually group them in one labelled block with the rule rendered as a chip / hint under the event type select. - Same treatment applies to read-only display surfaces (deadline detail page, approval-edit-modal read-only context section, project Verlauf timeline entries). ## Open design calls 1. Compound rendering shape — 'Event Type — Rule' (dash) vs 'Event Type (Rule)' (parens) vs Event Type on top + Rule as subtitle. 2. Empty-rule handling — when only event type is set, render the event type alone (no trailing dash). 3. Empty-event-type handling — when only rule is set, render the rule alone (rare; transitional state). ## Out of scope - Reshaping the proceeding-event-types catalog. - Changing the rule citation format inside the rule itself. - Cascading the same compound rendering to other entity types beyond deadlines. ## Role **coder direct** — visual reorder + compound rendering helper + i18n. Group with other small UI items.
mAi self-assigned this 2026-05-20 12:01:15 +00:00
mAi commented 2026-05-20 12:44:38 +00:00
Author
Collaborator
Copy Link

Shipped via euler's batch on mai/euler/coder-small-ux-polish, merged into main at https://mgit.msbls.de/m/paliad/commit/a5ae214. Live after next Dokploy deploy.

Shipped via euler's batch on `mai/euler/coder-small-ux-polish`, merged into main at https://mgit.msbls.de/m/paliad/commit/a5ae214. 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#56
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?