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

Deadline form overhaul: event-type modal search/filters, type→rule autofill, Auto mode, default-title button #82

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

m's reports (2026-05-25 12:56, 12:58, 12:59, 13:10)

Four related remarks, all touching the Create/Edit Deadline form. Bundled into one issue to avoid worker overlap.

Remark A — Event-type modal needs search + filters (12:56)

I want the event type selection modal to have a text search and a few filters - court type etc...

(Sample list pasted included Application for cost decision (UPC), Application to amend the patent (UPC), Counterclaim for Infringement (UPC), Defence to revocation (UPC), Notice of Appeal (EPO) (EPA), Notice of Opposition (EPO) (EPA), Appeal (DPMA) (DPMA), Opposition (DPMA) — court-type axis is clearly DPMA / UPC / EPA / …)

Remark B — Type → Rule auto-fill (12:58)

When the type is selected, the Rule should also be "autofilled" depending on the type.

AND we should have different sorting types. Maybe we can even do it "chronologically" in the proceeding, the logical sequence when we select "by proceeding type"

Remark C — Type/Rule clarity + "Auto" mode (12:59)

It needs to be more clear what the actual rule will be - and we need an "auto" option if it is already derived by the selected event type?

Remark D — Default-title button (13:10)

We should have a button for a "default title" for new deadlines / editing deadlines where we derive it from the Proceedings Info.

Scope

Part 1 — Event-type selection modal

  • Add a text search input at the top, search across all event-type labels (DE primary + EN fallback).
  • Add filter chips for court type: DPMA / UPC / EPA / others surfaced from the data.
  • Keep the existing category grouping (Submissions, …) but filters narrow visible groups (empty groups hide).
  • Sort within a group: alphabetical default.
  • Default selection: focus is on the search input on open.

Part 2 — Type → Rule auto-fill

  • When the user selects an event type, the Rule field auto-fills with the default rule mapped from that type.
    • Mapping source: likely paliad.deadline_rules WHERE event_type = ... AND is_default = true (or 1:1 by FK — verify schema). If no is_default column exists, surface this in the design and propose a column or a convention.
  • User can still override by explicitly picking a different rule.
  • Add sort options to the Rule selector: alphabetical, by court, by proceeding type (chronological / logical sequence within the proceeding).
    • "By proceeding type" sorts rules by their position in the proceeding's timeline (the same order they'd appear in Browse-a-proceeding). Requires a sequence / ordinal column on paliad.deadline_rules per proceeding-type, OR reuse whatever the projection service already uses for column placement.

Part 3 — Type/Rule contradiction copy + "Auto" option

Current state shows: Note: type contradicts rule — you have overridden the type.

Fix:

  • Add an "Auto" option to the Rule field — explicit, named "Auto (vom Typ abgeleitet: )" or similar. Visually distinct from a chosen rule.
  • Default state when Type is picked and no Rule is set: Rule = Auto (showing the derived rule name).
  • When user overrides with a non-Auto rule that contradicts the type, surface a clearer warning that names BOTH:
    • "Type derives rule: "
    • "Selected rule: "
    • " will be applied."
  • No silent overrides — what's applied is named.

Part 4 — Default-title button

  • Add a "Standardtitel" / "Default title" button next to the Title field on both Create and Edit forms.
  • Derives a sensible default from:
    • Project reference (e.g. C-UPC-0042)
    • Proceeding type (e.g. UPC-CoA)
    • Event type (e.g. "Application to Amend")
    • Parties / case caption (if compact)
    • Coder picks the recipe; document the format in the commit message so future templates can mirror it.
  • Clicking REPLACES the current title (with no destructive confirmation — the user invoked it explicitly).
  • Available even before Type is picked? Default to: button is enabled only when at least Type is set; if Type missing, derive from project + proceeding only.

Files most likely touched

  • frontend/src/deadlines.tsx + client (create/edit form components)
  • frontend/src/client/deadlines.ts or frontend/src/client/event-form.ts — type modal
  • frontend/src/client/i18n.ts — new keys for Auto, Standardtitel, filter labels
  • internal/handlers/deadlines.go — only if Auto-mode serialization needs a backend hook
  • DB: possibly an is_default flag on paliad.deadline_rules OR document why the convention (e.g. one rule per event_type marked otherwise) suffices

Hard rules

  • Don't break the existing flat-list selection — keep keyboard navigation + click-to-pick.
  • Don't silently change applied behavior — the warning copy must name the actually-applied rule.
  • go build ./... && go test ./internal/... && cd frontend && bun run build clean.
  • Branch: mai/<worker>/deadline-form-overhaul.

Out of scope

  • New event types or rule edits — only how they're chosen.
  • A separate event-type "create new type" affordance ("+ Add new type…" stays as a TBD link if already present).
  • Recurring-deadline support.

Reporting

mai report completed with branch + SHAs + the UX path for each Part (A: open form → click Type → search/filter modal works; B: pick Type → Rule auto-fills + sort options visible; C: explicit Auto badge + clearer override copy; D: click Standardtitel → field fills with formatted default).

## m's reports (2026-05-25 12:56, 12:58, 12:59, 13:10) Four related remarks, all touching the Create/Edit Deadline form. Bundled into one issue to avoid worker overlap. ### Remark A — Event-type modal needs search + filters (12:56) > I want the event type selection modal to have a text search and a few filters - court type etc... (Sample list pasted included `Application for cost decision` (UPC), `Application to amend the patent` (UPC), `Counterclaim for Infringement` (UPC), `Defence to revocation` (UPC), `Notice of Appeal (EPO)` (EPA), `Notice of Opposition (EPO)` (EPA), `Appeal (DPMA)` (DPMA), `Opposition (DPMA)` — court-type axis is clearly DPMA / UPC / EPA / …) ### Remark B — Type → Rule auto-fill (12:58) > When the type is selected, the Rule should also be "autofilled" depending on the type. > > AND we should have different sorting types. Maybe we can even do it "chronologically" in the proceeding, the logical sequence when we select "by proceeding type" ### Remark C — Type/Rule clarity + "Auto" mode (12:59) > It needs to be more clear what the actual rule will be - and we need an "auto" option if it is already derived by the selected event type? ### Remark D — Default-title button (13:10) > We should have a button for a "default title" for new deadlines / editing deadlines where we derive it from the Proceedings Info. ## Scope ### Part 1 — Event-type selection modal - Add a **text search input** at the top, search across all event-type labels (DE primary + EN fallback). - Add **filter chips** for court type: DPMA / UPC / EPA / others surfaced from the data. - Keep the existing category grouping (Submissions, …) but filters narrow visible groups (empty groups hide). - Sort within a group: alphabetical default. - Default selection: focus is on the search input on open. ### Part 2 — Type → Rule auto-fill - When the user selects an event type, the Rule field auto-fills with the default rule mapped from that type. - Mapping source: likely `paliad.deadline_rules WHERE event_type = ... AND is_default = true` (or 1:1 by FK — verify schema). If no `is_default` column exists, surface this in the design and propose a column or a convention. - User can still override by explicitly picking a different rule. - Add **sort options** to the Rule selector: alphabetical, by court, **by proceeding type** (chronological / logical sequence within the proceeding). - "By proceeding type" sorts rules by their position in the proceeding's timeline (the same order they'd appear in Browse-a-proceeding). Requires a `sequence` / `ordinal` column on `paliad.deadline_rules` per proceeding-type, OR reuse whatever the projection service already uses for column placement. ### Part 3 — Type/Rule contradiction copy + "Auto" option Current state shows: `Note: type contradicts rule — you have overridden the type.` Fix: - Add an **"Auto"** option to the Rule field — explicit, named "Auto (vom Typ abgeleitet: <rule name>)" or similar. Visually distinct from a chosen rule. - Default state when Type is picked and no Rule is set: Rule = Auto (showing the derived rule name). - When user overrides with a non-Auto rule that contradicts the type, surface a clearer warning that names BOTH: - "Type derives rule: <X>" - "Selected rule: <Y>" - "<Y> will be applied." - No silent overrides — what's applied is named. ### Part 4 — Default-title button - Add a **"Standardtitel"** / "Default title" button next to the Title field on both Create and Edit forms. - Derives a sensible default from: - Project reference (e.g. C-UPC-0042) - Proceeding type (e.g. UPC-CoA) - Event type (e.g. "Application to Amend") - Parties / case caption (if compact) - Coder picks the recipe; document the format in the commit message so future templates can mirror it. - Clicking REPLACES the current title (with no destructive confirmation — the user invoked it explicitly). - Available even before Type is picked? Default to: button is enabled only when at least Type is set; if Type missing, derive from project + proceeding only. ## Files most likely touched - `frontend/src/deadlines.tsx` + client (create/edit form components) - `frontend/src/client/deadlines.ts` or `frontend/src/client/event-form.ts` — type modal - `frontend/src/client/i18n.ts` — new keys for Auto, Standardtitel, filter labels - `internal/handlers/deadlines.go` — only if Auto-mode serialization needs a backend hook - DB: possibly an `is_default` flag on `paliad.deadline_rules` OR document why the convention (e.g. one rule per event_type marked otherwise) suffices ## Hard rules - Don't break the existing flat-list selection — keep keyboard navigation + click-to-pick. - Don't silently change applied behavior — the warning copy must name the actually-applied rule. - `go build ./... && go test ./internal/... && cd frontend && bun run build` clean. - Branch: `mai/<worker>/deadline-form-overhaul`. ## Out of scope - New event types or rule edits — only how they're chosen. - A separate event-type "create new type" affordance ("+ Add new type…" stays as a TBD link if already present). - Recurring-deadline support. ## Reporting `mai report completed` with branch + SHAs + the UX path for each Part (A: open form → click Type → search/filter modal works; B: pick Type → Rule auto-fills + sort options visible; C: explicit Auto badge + clearer override copy; D: click Standardtitel → field fills with formatted default).
mAi self-assigned this 2026-05-25 11:23:36 +00:00
mAi commented 2026-05-25 12:03:55 +00:00
Author
Collaborator
Copy Link

Done — branch mai/artemis/gitster-deadline-form

All four parts shipped in one commit: 8caaf6a

No schema migration; no new endpoint. All changes are client-side / CSS / i18n + two small TSX edits. Reuses paliad.deadline_concept_event_types (mig 072 / 074) — the existing concept→event_type mapping is just inverted to power Type→Rule.

Part A — Event-type modal: search + court filter chips

UX path. /deadlines/new → Typ field → click "Alle anzeigen" → modal opens with search input (autofocus) + chip row underneath (Alle Gerichte / UPC / EPA / DPMA / DE / Allgemein). Click a chip → list narrows. Search + chip filters intersect. Empty categories hide via the existing render path.

Touch. frontend/src/client/event-types.ts (openBrowseEventTypesModal), frontend/src/styles/global.css (.event-type-browse-chips, .event-type-browse-chip{,--active}). Chip jurisdictions are derived from the live data; any new flavour the admin adds lands at the end of the row automatically.

Part B — Type → Rule auto-fill + sort options

UX path. /deadlines/new → pick a Typ chip → Regel select auto-fills with the derived rule. Resolution: (1) exact match on project's proceeding_type_id if known, (2) jurisdiction match (EPA→EPO canon), (3) first candidate. Sort dropdown next to the Regel label switches between by Verfahrensablauf / by Gerichtsart (default) / alphabetisch. Sort preference persisted in localStorage per browser.

No new endpoint. Inversion is done in the client over the existing /api/deadline-rules payload — the rule already carries concept_default_event_type_id. "By Verfahrensablauf" groups by proceeding-type (sorted by proceeding_types.sort_order) and orders within by rule.sequence_order — same order the calculator emits, so the user reads it chronologically.

Touch. frontend/src/client/deadlines-new.ts (new functions: resolveAutoRuleForType, applyTypeAutoFillRule, renderRuleSelect), frontend/src/deadlines-new.tsx (sort dropdown), loadProceedingTypes() hits the existing /api/proceeding-types-db.

Part C — Auto rule mode + clearer override warning

UX path. Type picked → Regel select fills with the derived rule, AND a lime-tint Auto badge appears beneath: [Auto] — RoP.023 — Klageerwiderung. Manual rule pick → badge disappears immediately. If the manually-picked rule contradicts the type-derived one, a yellow warning surfaces that names BOTH: "Typ ergibt Regel: <X>. Gewählte Regel: <Y>. Es wird <Y> angewendet."

Discriminator. Symmetric lastAutoFilledRuleID sticky-replace flag mirrors the existing lastAutoFilledEventTypeID (t-paliad-165) — auto-fill only replaces its own previous suggestion, never a manual pick. Edge case: when Rule is auto-derived from Type, the existing collapsed Typ view ("Klageerwiderung (vorgegeben durch Regel)") is suppressed — it reads backwards in that direction.

Touch. frontend/src/client/deadlines-new.ts (refreshRuleAutoBadgeAndWarning), frontend/src/deadlines-new.tsx (auto-hint + override-warn slots), frontend/src/styles/global.css (.form-hint--auto, .form-hint-badge).

Part D — Standardtitel button

UX path. /deadlines/new → click "Standardtitel" next to the Titel label → field fills with derived default. /deadlines/{id} → enter edit mode → "Standardtitel" button appears under the title input → click to fill. No destructive confirmation because the user invoked it explicitly.

Recipe (documented here + in the commit so future templates can mirror it):

head = 1. event_type label (if exactly one Typ chip is set)
       2. rule code+name ("RoP.023 — Klageerwiderung")
       3. proceeding type name from project (create form only)
       4. fallback: t("deadlines.field.title.default_fallback") = "Neue Frist"
suffix = " — <project.reference>" when ref is set + not already in head

Examples:

  • Klageerwiderung — C-UPC-0042 — type known
  • RoP.023 — Klageerwiderung — REF — rule known, no type
  • UPC — Verletzungsverfahren — REF — only proceeding type
  • Neue Frist — REF — fallback

Touch. frontend/src/client/deadlines-new.ts (computeDefaultTitle), frontend/src/client/deadlines-detail.ts (edit-mode handler with show/hide on enter/exit), frontend/src/deadlines-new.tsx + frontend/src/deadlines-detail.tsx (button slots), frontend/src/styles/global.css (.btn-link-action, .form-field-label-row).

Build hygiene

  • go build ./... clean
  • go vet ./... clean
  • go test ./internal/... clean
  • cd frontend && bun run build clean (2786 keys, +10 new DE+EN, no scan warnings)

i18n keys added (DE + EN)

event_types.browse.jurisdiction.all
event_types.browse.jurisdiction.filter_label
deadlines.field.rule.auto_badge
deadlines.field.rule.override_warn
deadlines.field.rule.sort.by_proceeding
deadlines.field.rule.sort.by_court
deadlines.field.rule.sort.alpha
deadlines.field.rule.sort.other_proceeding
deadlines.field.title.default_btn
deadlines.field.title.default_fallback

Out of scope (intentionally)

  • No new event_types, no new rule edits.
  • No "+ Add new type" affordance change — it stays as the existing picker link.
  • No recurring-deadline support.
  • No backend endpoint change — the inverted mapping uses existing rule payload + the existing paliad.deadline_concept_event_types junction.

Ready for maria's review + merge. Awaiting head merge gate.

## Done — branch `mai/artemis/gitster-deadline-form` All four parts shipped in one commit: [`8caaf6a`](https://mgit.msbls.de/m/paliad/commit/8caaf6a631051457e1f175bb702a3df47a666771) No schema migration; no new endpoint. All changes are client-side / CSS / i18n + two small TSX edits. Reuses `paliad.deadline_concept_event_types` (mig 072 / 074) — the existing concept→event_type mapping is just inverted to power Type→Rule. ### Part A — Event-type modal: search + court filter chips **UX path.** /deadlines/new → Typ field → click "Alle anzeigen" → modal opens with search input (autofocus) + chip row underneath (Alle Gerichte / UPC / EPA / DPMA / DE / Allgemein). Click a chip → list narrows. Search + chip filters intersect. Empty categories hide via the existing render path. **Touch.** `frontend/src/client/event-types.ts` (`openBrowseEventTypesModal`), `frontend/src/styles/global.css` (`.event-type-browse-chips`, `.event-type-browse-chip{,--active}`). Chip jurisdictions are derived from the live data; any new flavour the admin adds lands at the end of the row automatically. ### Part B — Type → Rule auto-fill + sort options **UX path.** /deadlines/new → pick a Typ chip → Regel select auto-fills with the derived rule. Resolution: (1) exact match on project's `proceeding_type_id` if known, (2) jurisdiction match (EPA→EPO canon), (3) first candidate. Sort dropdown next to the Regel label switches between **by Verfahrensablauf** / **by Gerichtsart** (default) / **alphabetisch**. Sort preference persisted in `localStorage` per browser. **No new endpoint.** Inversion is done in the client over the existing `/api/deadline-rules` payload — the rule already carries `concept_default_event_type_id`. "By Verfahrensablauf" groups by proceeding-type (sorted by `proceeding_types.sort_order`) and orders within by `rule.sequence_order` — same order the calculator emits, so the user reads it chronologically. **Touch.** `frontend/src/client/deadlines-new.ts` (new functions: `resolveAutoRuleForType`, `applyTypeAutoFillRule`, `renderRuleSelect`), `frontend/src/deadlines-new.tsx` (sort dropdown), `loadProceedingTypes()` hits the existing `/api/proceeding-types-db`. ### Part C — Auto rule mode + clearer override warning **UX path.** Type picked → Regel select fills with the derived rule, AND a lime-tint **Auto** badge appears beneath: `[Auto] — RoP.023 — Klageerwiderung`. Manual rule pick → badge disappears immediately. If the manually-picked rule contradicts the type-derived one, a yellow warning surfaces that names BOTH: `"Typ ergibt Regel: <X>. Gewählte Regel: <Y>. Es wird <Y> angewendet."` **Discriminator.** Symmetric `lastAutoFilledRuleID` sticky-replace flag mirrors the existing `lastAutoFilledEventTypeID` (t-paliad-165) — auto-fill only replaces its own previous suggestion, never a manual pick. Edge case: when Rule is auto-derived from Type, the existing collapsed Typ view ("Klageerwiderung (vorgegeben durch Regel)") is suppressed — it reads backwards in that direction. **Touch.** `frontend/src/client/deadlines-new.ts` (`refreshRuleAutoBadgeAndWarning`), `frontend/src/deadlines-new.tsx` (auto-hint + override-warn slots), `frontend/src/styles/global.css` (`.form-hint--auto`, `.form-hint-badge`). ### Part D — Standardtitel button **UX path.** /deadlines/new → click "Standardtitel" next to the Titel label → field fills with derived default. /deadlines/{id} → enter edit mode → "Standardtitel" button appears under the title input → click to fill. No destructive confirmation because the user invoked it explicitly. **Recipe (documented here + in the commit so future templates can mirror it):** ``` head = 1. event_type label (if exactly one Typ chip is set) 2. rule code+name ("RoP.023 — Klageerwiderung") 3. proceeding type name from project (create form only) 4. fallback: t("deadlines.field.title.default_fallback") = "Neue Frist" suffix = " — <project.reference>" when ref is set + not already in head ``` **Examples:** - `Klageerwiderung — C-UPC-0042` — type known - `RoP.023 — Klageerwiderung — REF` — rule known, no type - `UPC — Verletzungsverfahren — REF` — only proceeding type - `Neue Frist — REF` — fallback **Touch.** `frontend/src/client/deadlines-new.ts` (`computeDefaultTitle`), `frontend/src/client/deadlines-detail.ts` (edit-mode handler with show/hide on enter/exit), `frontend/src/deadlines-new.tsx` + `frontend/src/deadlines-detail.tsx` (button slots), `frontend/src/styles/global.css` (`.btn-link-action`, `.form-field-label-row`). ### Build hygiene - `go build ./...` clean - `go vet ./...` clean - `go test ./internal/...` clean - `cd frontend && bun run build` clean (2786 keys, +10 new DE+EN, no scan warnings) ### i18n keys added (DE + EN) ``` event_types.browse.jurisdiction.all event_types.browse.jurisdiction.filter_label deadlines.field.rule.auto_badge deadlines.field.rule.override_warn deadlines.field.rule.sort.by_proceeding deadlines.field.rule.sort.by_court deadlines.field.rule.sort.alpha deadlines.field.rule.sort.other_proceeding deadlines.field.title.default_btn deadlines.field.title.default_fallback ``` ### Out of scope (intentionally) - No new event_types, no new rule edits. - No "+ Add new type" affordance change — it stays as the existing picker link. - No recurring-deadline support. - No backend endpoint change — the inverted mapping uses existing rule payload + the existing `paliad.deadline_concept_event_types` junction. Ready for maria's review + merge. Awaiting head merge gate.
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#82
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?