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

Submission templates: select court address + team members for letterhead (variable bag extension) #139

New Issue
Open
opened 2026-05-26 15:59:14 +00:00 by mAi · 0 comments
mAi commented 2026-05-26 15:59:14 +00:00
Collaborator
Copy Link

Goal (m, 2026-05-26 17:49)

In the submission-draft editor, lawyers should be able to:

  1. Select a court — pick which court's address goes on the document (defaults to the project's competent_court_id, but overridable for letters going to a different court / co-defendant's court / etc.). The chosen court's name + address fields flow into the template via {{court.*}} variables.
  2. Select team members for the letterhead — multi-select of users involved on this submission. Each picked member contributes their name, title, office address, phone, email to the variable bag as {{lawyer.1.*}}, {{lawyer.2.*}} etc. Same shape as the t-paliad-277 multi-party pattern.
  3. Use these in the Word template's letterhead block so the rendered .docx carries the right recipient + the right sender block per submission.

Existing data

  • Courts — internal/handlers/courts.go already carries full address per court (e.g. UPC-CD München: "Cincinnatistraße 64, 81549 München, Deutschland"). All UPC + DE Berufung + NL + Paris + Milan courts have it. No data gap on court side.
  • Users — paliad.users carries display_name, email, office (8-office enum), profession (partner/of_counsel/associate/senior_pa/pa/paralegal), job_title (free text), additional_offices[]. No DB gap for the names.
  • Office address — internal/offices/offices.go carries only {key, label_de, label_en} per office. Missing: street address, phone, fax per office. Same shape as courts.go — needs the 8 office addresses hardcoded.
  • Per-user phone — no direct_phone or fax column on paliad.users. Optional gap for individualised contact lines.

Scope (one issue, one branch — m's pick)

Data

  1. Extend internal/offices/offices.go to add Address + Phone per office (hardcoded directory). Head needs the 8 office addresses from m before dispatch — see open question §A below.
  2. Add direct_phone text NULL, fax text NULL to paliad.users (additive migration, no set_config needed since user-table mutations don't fire the deadline_rules audit trigger — verify via Supabase MCP audit). User edits via the existing /profile page (add the two fields). NOT a blocker — letterhead can render an empty phone line until users fill it.

Submission-draft editor UI

  1. Court picker: dropdown in the submission-draft editor, pre-populated from project.competent_court_id. Reads the courts catalog (already an HTTP endpoint at /api/courts). Selected court_id stored on paliad.submission_drafts (new nullable column selected_court_id).
  2. Lawyer multi-select: multi-select of team members for this project. The project_team_members list filters the user table. Selected user_ids stored as selected_lawyers uuid[] on paliad.submission_drafts.
  3. Both selectors live in a new "Briefkopf / Letterhead" collapsible section above the variable form. UI matches the existing perspective+date strip pattern.

Variable bag (internal/services/submission_vars.go)

  1. Add {{court.name}}, {{court.name_en}}, {{court.address}}, {{court.city}}, {{court.country}} populated from the selected court (or empty when none selected).
  2. Add {{lawyers.N.name}}, {{lawyers.N.title}} (= job_title || profession_label), {{lawyers.N.email}}, {{lawyers.N.office}}, {{lawyers.N.office_address}}, {{lawyers.N.office_phone}}, {{lawyers.N.direct_phone}} for N ∈ [1, len(selected_lawyers)]. Mirror the existing multi-party emit-grouping pattern in emitPartyGroup.
  3. Also expose joined-list aliases like {{lawyers.names}} (comma-joined) and {{lawyers.offices}} for free-text letterhead variants — same way {{parties.claimants}} works.
  4. Cover with unit tests in submission_vars_*_test.go.

Word template hookup

  1. Not in scope of this slice: editorial work to actually USE the new variables in the existing de.inf.lg.erwidg.docx's letterhead block — that's m authoring the template in Word + push to mWorkRepo. Document the variable list in the README so template authors know what's available.

Open questions for head before dispatch

  • §A — m needs to supply the 8 office addresses (or paste them somewhere head can find them). Defaults: HLC's published office addresses, probably the same as hoganlovells.com site footer. If m doesn't have time today, head can stub Address: "" for now and lawyers fill it via a follow-up.
  • §B — direct_phone and fax: ship as optional columns now or skip entirely until someone asks for per-user phone lines? Recommended: ship now (cheap, harmless, additive).

Hard rules (lessons from today's mig 134 hotfix-3)

  • MUST audit live schema via mcp__supabase__execute_sql BEFORE drafting the migration. Specifically: confirm direct_phone/fax don't already exist on paliad.users; confirm selected_court_id/selected_lawyers don't already exist on paliad.submission_drafts; confirm no audit trigger on either table that requires set_config. Today's mig 134 had 3 hotfixes from skipped audits.
  • English identifiers in pkg/litigationplanner-adjacent code; pure logic where possible; tests follow code.
  • No updated_at = now() writes unless the column exists (it does on paliad.users and paliad.submission_drafts — verify both before any UPDATE).

Acceptance

  1. Submission-draft editor shows the Briefkopf section with court dropdown + lawyer multi-select.
  2. Switching court / picking lawyers updates the variable preview live.
  3. Word render via /api/submission_drafts/{id}/render produces a .docx with {{court.*}} and {{lawyers.N.*}} substituted.
  4. Re-opening a saved draft restores the court + lawyer selection.
  5. go test ./... + bun run build clean.
  6. Migration applies cleanly via in-process boot path.
## Goal (m, 2026-05-26 17:49) In the submission-draft editor, lawyers should be able to: 1. **Select a court** — pick which court's address goes on the document (defaults to the project's `competent_court_id`, but overridable for letters going to a different court / co-defendant's court / etc.). The chosen court's name + address fields flow into the template via `{{court.*}}` variables. 2. **Select team members for the letterhead** — multi-select of users involved on this submission. Each picked member contributes their name, title, office address, phone, email to the variable bag as `{{lawyer.1.*}}`, `{{lawyer.2.*}}` etc. Same shape as the t-paliad-277 multi-party pattern. 3. **Use these in the Word template's letterhead block** so the rendered .docx carries the right recipient + the right sender block per submission. ## Existing data - **Courts** — `internal/handlers/courts.go` already carries full address per court (e.g. *UPC-CD München: "Cincinnatistraße 64, 81549 München, Deutschland"*). All UPC + DE Berufung + NL + Paris + Milan courts have it. **No data gap on court side.** - **Users** — `paliad.users` carries `display_name`, `email`, `office` (8-office enum), `profession` (partner/of_counsel/associate/senior_pa/pa/paralegal), `job_title` (free text), `additional_offices[]`. **No DB gap for the names.** - **Office address** — `internal/offices/offices.go` carries only `{key, label_de, label_en}` per office. **Missing: street address, phone, fax per office.** Same shape as `courts.go` — needs the 8 office addresses hardcoded. - **Per-user phone** — no `direct_phone` or `fax` column on `paliad.users`. **Optional gap** for individualised contact lines. ## Scope (one issue, one branch — m's pick) ### Data 1. Extend `internal/offices/offices.go` to add `Address` + `Phone` per office (hardcoded directory). Head needs the 8 office addresses from m before dispatch — see open question §A below. 2. Add `direct_phone text NULL`, `fax text NULL` to `paliad.users` (additive migration, no `set_config` needed since user-table mutations don't fire the deadline_rules audit trigger — verify via Supabase MCP audit). User edits via the existing `/profile` page (add the two fields). NOT a blocker — letterhead can render an empty phone line until users fill it. ### Submission-draft editor UI 3. **Court picker**: dropdown in the submission-draft editor, pre-populated from `project.competent_court_id`. Reads the courts catalog (already an HTTP endpoint at `/api/courts`). Selected court_id stored on `paliad.submission_drafts` (new nullable column `selected_court_id`). 4. **Lawyer multi-select**: multi-select of team members for this project. The project_team_members list filters the user table. Selected user_ids stored as `selected_lawyers uuid[]` on `paliad.submission_drafts`. 5. Both selectors live in a new "Briefkopf / Letterhead" collapsible section above the variable form. UI matches the existing perspective+date strip pattern. ### Variable bag (`internal/services/submission_vars.go`) 6. Add `{{court.name}}`, `{{court.name_en}}`, `{{court.address}}`, `{{court.city}}`, `{{court.country}}` populated from the selected court (or empty when none selected). 7. Add `{{lawyers.N.name}}`, `{{lawyers.N.title}}` (= `job_title` || `profession_label`), `{{lawyers.N.email}}`, `{{lawyers.N.office}}`, `{{lawyers.N.office_address}}`, `{{lawyers.N.office_phone}}`, `{{lawyers.N.direct_phone}}` for N ∈ [1, len(selected_lawyers)]. Mirror the existing multi-party emit-grouping pattern in `emitPartyGroup`. 8. Also expose joined-list aliases like `{{lawyers.names}}` (comma-joined) and `{{lawyers.offices}}` for free-text letterhead variants — same way `{{parties.claimants}}` works. 9. Cover with unit tests in `submission_vars_*_test.go`. ### Word template hookup 10. **Not in scope of this slice**: editorial work to actually USE the new variables in the existing `de.inf.lg.erwidg.docx`'s letterhead block — that's m authoring the template in Word + push to mWorkRepo. Document the variable list in the README so template authors know what's available. ## Open questions for head before dispatch - **§A** — m needs to supply the 8 office addresses (or paste them somewhere head can find them). Defaults: HLC's published office addresses, probably the same as `hoganlovells.com` site footer. If m doesn't have time today, head can stub `Address: ""` for now and lawyers fill it via a follow-up. - **§B** — direct_phone and fax: ship as optional columns now or skip entirely until someone asks for per-user phone lines? Recommended: ship now (cheap, harmless, additive). ## Hard rules (lessons from today's mig 134 hotfix-3) - **MUST audit live schema** via `mcp__supabase__execute_sql` BEFORE drafting the migration. Specifically: confirm `direct_phone`/`fax` don't already exist on `paliad.users`; confirm `selected_court_id`/`selected_lawyers` don't already exist on `paliad.submission_drafts`; confirm no audit trigger on either table that requires `set_config`. Today's mig 134 had 3 hotfixes from skipped audits. - English identifiers in pkg/litigationplanner-adjacent code; pure logic where possible; tests follow code. - No `updated_at = now()` writes unless the column exists (it does on `paliad.users` and `paliad.submission_drafts` — verify both before any UPDATE). ## Acceptance 1. Submission-draft editor shows the Briefkopf section with court dropdown + lawyer multi-select. 2. Switching court / picking lawyers updates the variable preview live. 3. Word render via `/api/submission_drafts/{id}/render` produces a .docx with `{{court.*}}` and `{{lawyers.N.*}}` substituted. 4. Re-opening a saved draft restores the court + lawyer selection. 5. `go test ./...` + `bun run build` clean. 6. Migration applies cleanly via in-process boot path.
mAi self-assigned this 2026-05-26 15:59:14 +00:00
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#139
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?