Submission generator — unified auto-naming scheme (date · initiator · …) + customizable #155

Open
opened 2026-05-27 22:38:35 +00:00 by mAi · 0 comments
Collaborator

Request (m, 2026-05-28 00:37)

can we have our submission generator generally have a unified naming scheme where the date comes first, then the "initiator" ... the automated name should be customizable somewhere

Shape

  • Default pattern: <date> <initiator> <…> — date leads, then the initiator (party filing? lawyer drafting? case reference?), then the rest.
  • Customizable somewhere — a single place that controls the auto-generated submission name, so a firm / user / template can tweak without code changes.

Today's state

Auto-naming logic likely lives in internal/services/submission_draft_service.go or submission_base_service.go (whatever fills the default title on a freshly-created draft). Quick audit needed to confirm current pattern and where the format string lives.

Decisions to lock before implementing (worth a quick m grilling)

  1. What is "initiator"?
    • Filing party (claimant/defendant/court)
    • Drafting lawyer (current user)
    • Case reference (project.case_number)
    • Something else
  2. What date?
    • Today (draft creation date)
    • The deadline date the submission is for
    • The intended filing date (if known)
  3. Format spec
    • Date format: YYYY-MM-DD (sortable, ISO) or DD.MM.YYYY (German conventional)?
    • Separator: · / / - / _ ?
    • Spaces in tokens? (e.g. firm names with spaces)
  4. Customization scope — where the override lives:
    • Per user (each lawyer's preference; user.settings JSON)
    • Firm-wide (admin setting; one pattern for all HLC users)
    • Per submission template (different bases override the pattern — e.g. UPC SoC vs DE Klageerwiderung)
    • All three (cascade: template > user > firm > built-in default)
  5. Format string grammar — define the syntax:
    • Go template ({{.Date}} {{.Initiator}} {{.Caseref}}) — flexible but lawyer-unfriendly
    • Simple tokens (%date% %initiator% %caseref%) — friendlier, less power
    • YAML/JSON config struct (no string template — explicit fields ordered) — least flexible, most validated

Acceptance (high level)

  • New draft auto-name follows the pattern; default is <date> <initiator> per m's brief
  • Override surface visible in settings (location TBD per Q4)
  • Tests cover the cascade if multi-level (Q4)
  • Existing drafts not retroactively renamed

NOT

  • Not blocking — the prod-500 fire (m/paliad#154) takes precedence.
  • Not in this train — this is a fresh feature, separate inventor/coder cycle.
  • Bump after the current Litigation Builder train (B3+) lands, unless m says sooner.
## Request (m, 2026-05-28 00:37) > can we have our submission generator generally have a unified naming scheme where the date comes first, then the "initiator" ... the automated name should be customizable somewhere ## Shape - **Default pattern**: `<date> <initiator> <…>` — date leads, then the initiator (party filing? lawyer drafting? case reference?), then the rest. - **Customizable somewhere** — a single place that controls the auto-generated submission name, so a firm / user / template can tweak without code changes. ## Today's state Auto-naming logic likely lives in `internal/services/submission_draft_service.go` or `submission_base_service.go` (whatever fills the default title on a freshly-created draft). Quick audit needed to confirm current pattern and where the format string lives. ## Decisions to lock before implementing (worth a quick m grilling) 1. **What is "initiator"?** - Filing party (claimant/defendant/court) - Drafting lawyer (current user) - Case reference (project.case_number) - Something else 2. **What date?** - Today (draft creation date) - The deadline date the submission is for - The intended filing date (if known) 3. **Format spec** - Date format: `YYYY-MM-DD` (sortable, ISO) or `DD.MM.YYYY` (German conventional)? - Separator: ` · ` / ` — ` / ` - ` / `_` ? - Spaces in tokens? (e.g. firm names with spaces) 4. **Customization scope** — where the override lives: - **Per user** (each lawyer's preference; user.settings JSON) - **Firm-wide** (admin setting; one pattern for all HLC users) - **Per submission template** (different bases override the pattern — e.g. UPC SoC vs DE Klageerwiderung) - **All three** (cascade: template > user > firm > built-in default) 5. **Format string grammar** — define the syntax: - Go template (`{{.Date}} {{.Initiator}} {{.Caseref}}`) — flexible but lawyer-unfriendly - Simple tokens (`%date% %initiator% %caseref%`) — friendlier, less power - YAML/JSON config struct (no string template — explicit fields ordered) — least flexible, most validated ## Acceptance (high level) - New draft auto-name follows the pattern; default is `<date> <initiator>` per m's brief - Override surface visible in settings (location TBD per Q4) - Tests cover the cascade if multi-level (Q4) - Existing drafts not retroactively renamed ## NOT - Not blocking — the prod-500 fire (m/paliad#154) takes precedence. - Not in this train — this is a fresh feature, separate inventor/coder cycle. - Bump after the current Litigation Builder train (B3+) lands, unless m says sooner.
mAi self-assigned this 2026-05-27 22:38:35 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/paliad#155
No description provided.