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

Project form: drop 'Wir vertreten' for clients; rename to 'Client Role' on case projects with new option set #47

New Issue
Open
opened 2026-05-20 11:35:01 +00:00 by mAi · 2 comments
mAi commented 2026-05-20 11:35:01 +00:00
Collaborator
Copy Link

Trigger

m 2026-05-20 13:32:

When creating a client we should not ask 'we represent...' and provide a side selection. The client is only the client. This only plays a role in case projects — and even there the question should be 'Client Role...' and the selection should be Active (Claimant / Applicant / Appealant) or Reactive (Defendant / Respondent) or Third Party / Other.

Current state (verified 2026-05-20)

  • paliad.projects.our_side text column, CHECK constraint allows ('claimant', 'defendant', 'court', 'both', NULL) (mig 072).
  • Rendered for every project type by frontend/src/components/ProjectFormFields.tsx:157-167 with label Wir vertreten and 5 options (Unbekannt, Klägerseite, Beklagtenseite, Gericht / Tribunal, Beide Seiten).
  • Downstream consumers:
    • Fristenrechner Determinator uses our_side to predefine the perspective chip (Slice 3c lock-in).
    • Submission templates use {{project.our_side}} / our_side_de / our_side_en placeholders (services/submission_vars.go).
    • Project events log our_side_changed audit rows.

What m wants

Visibility

  • type='client': field hidden entirely. A client is just a client; no client-role on the org-level project.
  • type='case': field renamed to 'Client Role' (projects.field.client_role or similar) with the new option set.
  • type='litigation', type='patent': m's wording implies hide here too ("only plays a role in case projects"). Verify in design.

New option set (case projects)

m grouped the options in three buckets:

  • Active — Claimant / Applicant / Appellant
  • Reactive — Defendant / Respondent
  • Third Party / Other

Design call: does the stored value capture the group (Active / Reactive / Third Party) or the sub-role (Claimant / Applicant / Appellant / Defendant / Respondent / Third Party / Other)?

  • (R) sub-role (7 distinct values). Lawyers care about the specific posture; sub-role can be aggregated up at display time if needed. Aligns with how UPC docs cite the proceedings (Applicant ≠ Claimant in some procedural contexts).
  • Alternative: group only (3 values). Simpler schema, less precise display. Existing 'claimant' / 'defendant' rows would need a mapping.

The picker UX is a single select with optgroups (visual grouping under Active / Reactive / Third Party / Other headers), not a 2-step picker — same density as the current Wir-vertreten field, just with new labels.

Schema migration

  • Widen the projects_our_side_check CHECK constraint to include the new values: 'applicant', 'appellant', 'respondent', 'third_party', 'other'. Keep 'claimant', 'defendant' (still valid). Drop 'court' and 'both' from the CHECK (m's new set has no equivalent — court was always semantically odd here; both was a fallback). Existing rows: backfill 'court'/'both' → NULL with a one-time migration (audit-trail-friendly).
  • Optionally rename the column our_side → client_role to match the new label. Has wider blast radius (Fristenrechner code, submission_vars, project events, JSON keys in API responses) — design call. Keeping our_side is the smaller change.

Downstream coordination

  • Fristenrechner Determinator: Slice 3c our_side → perspective inference. The Active group maps to claimant-perspective; Reactive to defendant-perspective. Confirm in design.
  • Submission templates: {{project.our_side_de}} / _en already render legal-prose forms (e.g. 'die Klägerseite' / 'on the claimant side'). New values need new translations. Design list the prose forms in DE + EN.
  • Project events: our_side_changed audit emission keeps firing on writes; only the label changes.
  • Existing data: 'court' rows (?) — check live data; if any exist, handle them in the migration with a default fallback.

Acceptance

  • Creating a project of type='client' does NOT show the field.
  • Creating a project of type='case' shows the field labelled 'Client Role' (DE: 'Mandantenrolle' or similar) with the 7 new options grouped under 3 optgroup headers.
  • Existing 'court' and 'both' rows are migrated to NULL (or m-chosen fallback).
  • Submission templates that referenced project.our_side_de / _en keep rendering coherent prose for the new values.
  • Fristenrechner Determinator perspective still pre-fills correctly.

Out of scope

  • Reshaping parties table (project-party roles are a separate concern; they're stored per row already).
  • New analytics / reports breaking out the new sub-roles.
  • Bulk-renaming existing user-facing copy that says 'Klägerseite' / 'Beklagtenseite' outside this form.

Role recommendation

inventor — small but with 3-4 design calls (sub-role vs group; column rename vs keep; litigation/patent type behaviour; data migration of court/both rows). Head batches m's picks across the design questions; coder shift after. Branch: mai/<inventor>/client-role-rework.

## Trigger m 2026-05-20 13:32: > When creating a client we should not ask 'we represent...' and provide a side selection. The client is only the client. This only plays a role in case projects — and even there the question should be 'Client Role...' and the selection should be Active (Claimant / Applicant / Appealant) or Reactive (Defendant / Respondent) or Third Party / Other. ## Current state (verified 2026-05-20) - `paliad.projects.our_side` text column, CHECK constraint allows `('claimant', 'defendant', 'court', 'both', NULL)` (mig 072). - Rendered for **every** project type by `frontend/src/components/ProjectFormFields.tsx:157-167` with label `Wir vertreten` and 5 options (Unbekannt, Klägerseite, Beklagtenseite, Gericht / Tribunal, Beide Seiten). - Downstream consumers: - Fristenrechner Determinator uses `our_side` to predefine the perspective chip (Slice 3c lock-in). - Submission templates use `{{project.our_side}}` / `our_side_de` / `our_side_en` placeholders (services/submission_vars.go). - Project events log `our_side_changed` audit rows. ## What m wants ### Visibility - **type='client'**: field hidden entirely. A client is just a client; no client-role on the org-level project. - **type='case'**: field renamed to **'Client Role'** (`projects.field.client_role` or similar) with the new option set. - **type='litigation', type='patent'**: m's wording implies hide here too ("only plays a role in case projects"). Verify in design. ### New option set (case projects) m grouped the options in three buckets: - **Active** — Claimant / Applicant / Appellant - **Reactive** — Defendant / Respondent - **Third Party / Other** Design call: does the **stored value** capture the group (Active / Reactive / Third Party) or the sub-role (Claimant / Applicant / Appellant / Defendant / Respondent / Third Party / Other)? - **(R)** sub-role (7 distinct values). Lawyers care about the specific posture; sub-role can be aggregated up at display time if needed. Aligns with how UPC docs cite the proceedings (Applicant ≠ Claimant in some procedural contexts). - Alternative: group only (3 values). Simpler schema, less precise display. Existing 'claimant' / 'defendant' rows would need a mapping. The picker UX is a **single select with optgroups** (visual grouping under Active / Reactive / Third Party / Other headers), not a 2-step picker — same density as the current Wir-vertreten field, just with new labels. ## Schema migration - Widen the `projects_our_side_check` CHECK constraint to include the new values: `'applicant', 'appellant', 'respondent', 'third_party', 'other'`. Keep `'claimant', 'defendant'` (still valid). Drop `'court'` and `'both'` from the CHECK (m's new set has no equivalent — court was always semantically odd here; both was a fallback). Existing rows: backfill `'court'`/`'both'` → NULL with a one-time migration (audit-trail-friendly). - Optionally **rename the column** `our_side` → `client_role` to match the new label. Has wider blast radius (Fristenrechner code, submission_vars, project events, JSON keys in API responses) — design call. Keeping `our_side` is the smaller change. ## Downstream coordination - **Fristenrechner Determinator**: Slice 3c `our_side` → perspective inference. The Active group maps to claimant-perspective; Reactive to defendant-perspective. Confirm in design. - **Submission templates**: `{{project.our_side_de}}` / `_en` already render legal-prose forms (e.g. 'die Klägerseite' / 'on the claimant side'). New values need new translations. Design list the prose forms in DE + EN. - **Project events**: `our_side_changed` audit emission keeps firing on writes; only the label changes. - **Existing data**: 'court' rows (?) — check live data; if any exist, handle them in the migration with a default fallback. ## Acceptance - Creating a project of type='client' does NOT show the field. - Creating a project of type='case' shows the field labelled 'Client Role' (DE: 'Mandantenrolle' or similar) with the 7 new options grouped under 3 optgroup headers. - Existing 'court' and 'both' rows are migrated to NULL (or m-chosen fallback). - Submission templates that referenced `project.our_side_de` / `_en` keep rendering coherent prose for the new values. - Fristenrechner Determinator perspective still pre-fills correctly. ## Out of scope - Reshaping `parties` table (project-party roles are a separate concern; they're stored per row already). - New analytics / reports breaking out the new sub-roles. - Bulk-renaming existing user-facing copy that says 'Klägerseite' / 'Beklagtenseite' outside this form. ## Role recommendation **inventor** — small but with 3-4 design calls (sub-role vs group; column rename vs keep; litigation/patent type behaviour; data migration of court/both rows). Head batches m's picks across the design questions; coder shift after. Branch: `mai/<inventor>/client-role-rework`.
mAi self-assigned this 2026-05-20 11:35:01 +00:00
mAi commented 2026-05-20 12:51:17 +00:00
Author
Collaborator
Copy Link

Implemented in PR #67 (#67) — paired with #50.

Design decisions (all picks confirmed by head):

  • Column stays our_side (UI label changes only to "Client Role")
  • 7 distinct sub-role values; grouped at display time into 3 optgroups
  • Hidden on client, litigation, patent, project, other types — visible only on case
  • Sub-role flip-map for CCR: applicant ↔ respondent, appellant → respondent
  • DE prose uses gender-neutral -Seite/-Partei shape (Klägerseite / Antragstellerseite / …) to match form labels and avoid a feminine bare-noun default that misrepresents B2B clients

Final SHA: d326acb. Migration: mig 112 (rebumped from 110→111→112 to dodge euler/gauss slot collisions).

Deploy via auto-webhook on merge.

Implemented in PR #67 (https://mgit.msbls.de/m/paliad/pulls/67) — paired with #50. Design decisions (all picks confirmed by head): - Column stays `our_side` (UI label changes only to "Client Role") - 7 distinct sub-role values; grouped at display time into 3 optgroups - Hidden on `client`, `litigation`, `patent`, `project`, `other` types — visible only on `case` - Sub-role flip-map for CCR: applicant ↔ respondent, appellant → respondent - DE prose uses gender-neutral `-Seite`/`-Partei` shape (Klägerseite / Antragstellerseite / …) to match form labels and avoid a feminine bare-noun default that misrepresents B2B clients Final SHA: d326acb. Migration: mig 112 (rebumped from 110→111→112 to dodge euler/gauss slot collisions). Deploy via auto-webhook on merge.
mAi commented 2026-05-20 12:56:29 +00:00
Author
Collaborator
Copy Link

Shipped via kepler on mai/kepler/inventorcoder-project — merged into main; commit https://mgit.msbls.de/m/paliad/commit/1c021ed. Live after next Dokploy deploy.

Shipped via kepler on `mai/kepler/inventorcoder-project` — merged into main; commit https://mgit.msbls.de/m/paliad/commit/1c021ed. 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#47
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?