t-paliad-252. Replace the silent confirm()-then-DELETE with a three-path
warning modal: Cancel / Edit event (primary) / Withdraw and delete
(destructive). The edit-instead path lets the requester revise the
in-flight entity without withdrawing the approval request.
Backend — new service method + endpoint
- ApprovalService.EditPendingEntity(requestID, callerID, fields):
- validates caller == requested_by AND status = pending
- reuses the existing wider counter-allowlist (buildCounterSetClauses
from SuggestChanges) — every editable field on the entity, not just
the date triggers
- applies the field updates to the entity row via applyEntityUpdate
(including the event_type_ids junction rewrite for deadlines)
- merges new fields into approval_requests.payload (jsonb) so the
approver inbox sees what was revised
- emits a distinct *_approval_edited_by_requester project_event so the
Verlauf surfaces the revision separately from the original *_requested
row and any decision row
- request stays pending; entity.approval_status stays pending
- POST /api/approval-requests/{id}/edit-entity
- Body: {"fields": {<entity-shape>}}
- Errors reuse the existing mapApprovalError mapping:
400 suggestion_requires_change, 403 not_authorized,
404, 409 request_not_pending
- Distinguishing audit event types per the spec:
- destructive Withdraw path: existing <entity>_approval_revoked
(no behaviour change — for CREATE deletes the entity, for UPDATE /
COMPLETE reverts to pre_image, for DELETE cancels the delete request)
- edit-instead path: new <entity>_approval_edited_by_requester
Frontend — shared withdraw warning modal
- frontend/src/client/components/withdraw-warning-modal.ts
- Built on the unified openModal() primitive (t-paliad-217 Slice A)
- Primary CTA "Termin bearbeiten" highlights the non-destructive path
- Secondary defaults to "Abbrechen" (handled by openModal)
- Destructive button "Endgültig zurückziehen und löschen" lives inside
the body (red, separated by a dashed border) so the safe path stays
visually primary in the footer
- Copy adapts per lifecycle:
CREATE → "Wenn Sie zurückziehen, wird die Frist/der Termin gelöscht."
UPDATE → "Ihre vorgeschlagenen Änderungen werden verworfen."
DELETE → "Der Eintrag bleibt bestehen."
Frontend — wiring on both detail pages
- deadlines-detail.ts + appointments-detail.ts:
- Replace confirm() in withdraw flow with openWithdrawWarningModal()
- Edit path: set module-level pendingEditMode = true + enter edit mode
(override existing pending-state freeze on appointments; expose
enterEdit() via late-bound pendingEnterEdit on deadlines)
- Save handler in pendingEditMode routes to /edit-entity instead of
PATCH /api/<entity>/{id} (which still 409s on pending state)
- Destructive Withdraw path: existing /revoke endpoint unchanged
- For CREATE-lifecycle revokes the entity is gone — bounce to the
/events list instead of trying to re-fetch (was reload() before)
i18n: +14 keys DE+EN under approvals.withdraw.* (modal title, primary,
destructive, cancel, lead.create.{deadline,appointment}, lead.update,
lead.delete, sub.create, sub.update, sub.delete)
CSS: .withdraw-warning-body + .withdraw-warning-{intro,sub,
destructive-row,destructive-btn} — lime-tint sibling palette consistent
with the existing form-hint pattern; destructive button uses .btn-danger.
Build hygiene:
- go build + go vet + go test ./internal/... clean
- frontend bun run build clean (2807 keys, +14 new, scan clean)
Files of note:
- internal/services/approval_service.go (EditPendingEntity + sortedKeys
helper; maps.Copy for the payload merge)
- internal/handlers/approvals.go (handleEditPendingEntity)
- internal/handlers/handlers.go (route registration)
- frontend/src/client/components/withdraw-warning-modal.ts (new shared
component)
- frontend/src/client/deadlines-detail.ts (initWithdraw rewrite + Save
pending-edit branch)
- frontend/src/client/appointments-detail.ts (withdrawAppointmentRequest
rewrite + Save pending-edit branch + form-freeze respects
pendingEditMode)
Out of scope (intentionally):
- Reopening already-deleted approval requests (the destructive path
stays final).
- Approval-request analytics / metrics.
- Notifying the original approval-requester via channel.
paliad
Paliad — all-in-one patent practice platform for HLC (formerly Hogan Lovells). Knowledge tools and Aktenverwaltung behind one sidebar.
- Aktenverwaltung: Akten (matters), Fristen (deadlines), Termine (appointments) with CalDAV sync, Parteien, Dashboard. Office-scoped visibility with explicit collaborators.
- Knowledge tools: Prozesskostenrechner (DE / UPC / EPA), Fristenrechner, Gebührentabellen, Patentglossar, Gerichtsverzeichnis, Checklisten, Link Hub, Downloads.
Domain: paliad.de (legacy: patholo.de, patholo.msbls.de).
Repo: m/paliad on mgit.msbls.de.
Stack
- Frontend: Bun + custom JSX/TSX renderer (no React), per-page client TS bundles, HTML-first forms
- Backend: Go (
net/http),sqlxfor DB access - Migrations:
golang-migrate/migrate/v4with SQL files embedded viaembed.FS; applied at server startup before the HTTP listener binds - Database: youpc Supabase Postgres,
paliadschema. Office-scoped RLS (paliad.can_see_akte(akte_id)) — seedocs/design-kanzlai-integration.md§2 - Auth: Supabase password (cookie session,
@hoganlovells.com/@hlc.*email gate) - CalDAV: hand-rolled iCal + minimal WebDAV client in
internal/services/caldav_*.go; AES-GCM at rest for stored passwords - Hosting: Dokploy compose
Zx147ycurfYagKRl_Zzyoon mlake
Database migrations
Migrations live in internal/db/migrations/ as NNN_description.up.sql + .down.sql pairs. They are embedded into the Go binary via embed.FS and applied automatically at server startup (before the HTTP listener binds) when DATABASE_URL is set.
The migration tracker is paliad.paliad_schema_migrations (not the default public.schema_migrations). This avoids a collision with other apps on the shared youpc Supabase instance — see the memory episode "paliad migration bootstrap collision with shared Postgres" for the incident that drove the change.
Current migrations (as of April 2026):
001_paliad_schema schema + extensions
002_users paliad.users (office, role, practice_group)
003_reference_tables proceeding_types, deadline_rules, holidays
004_akten paliad.akten with visibility columns
005_akten_children parteien, fristen, termine, dokumente, akten_events, notizen
006_visibility paliad.can_see_akte() function
007_rls_policies RLS on every paliad table
008_seed_proceeding_types
009_seed_deadline_rules 32 UPC + 4 ZPO rules
010_seed_holidays DE federal + UPC judicial vacations
011_feedback_tables link_suggestions, checklisten_feedback, gerichte_feedback
012_fristenrechner_rules DB-backed rule set for /tools/fristenrechner
013_user_caldav_config per-user CalDAV (encrypted) + sync log
014_checklist_instances persisted checklist instances linkable to Akten
Add a new migration:
internal/db/migrations/015_<description>.up.sql
internal/db/migrations/015_<description>.down.sql
The down file is required and must reverse the up cleanly (verified by adding a one-off down test before merge).
To run migrations against a local Postgres:
docker run -d --name paliad-pg -e POSTGRES_PASSWORD=test -p 5432:5432 postgres:16-alpine
# bootstrap a mock auth schema (auth.users + auth.uid()) — required because
# the migrations reference Supabase-provided objects:
psql postgres://postgres:test@localhost:5432/postgres -f internal/db/devtools/mock_supabase_auth.sql
DATABASE_URL='postgres://postgres:test@localhost:5432/postgres?sslmode=disable' \
SUPABASE_URL=stub SUPABASE_ANON_KEY=stub \
go run ./cmd/server
Environment
| Variable | Required | Purpose |
|---|---|---|
PORT |
no (default 8080) | HTTP listen port |
SUPABASE_URL |
yes | Supabase project URL (auth) |
SUPABASE_ANON_KEY |
yes | Supabase anon key (auth) |
DATABASE_URL |
for Aktenverwaltung | Direct Postgres conn for migrations + Akten/Fristen/Termine services. Knowledge-platform endpoints (Kostenrechner, Glossar, Links, Gebührentabellen, Checklisten, Gerichte, Downloads) don't use the pool and work without it. Aktenverwaltung endpoints return 503 if unset. |
CALDAV_ENCRYPTION_KEY |
for CalDAV sync | 32-byte AES-256 key, base64-encoded. Encrypts CalDAV passwords at rest (AES-GCM). Server fails fast on malformed key; if unset, CalDAV is silently disabled (/api/caldav-config returns 501). Generate with openssl rand -base64 32. |
GITEA_TOKEN |
optional | Gitea API token for the private file proxy (Downloads) |
ANTHROPIC_API_KEY |
not used today | Reserved for Phase H (AI Frist-Extraktion). Currently deferred — do not set. |
Development
make build # compile backend + frontend
make test # run Go tests + frontend tests
go build ./... # backend only
go vet ./... # static checks
go test ./... # Go tests
bun run build # frontend only (produces frontend/dist/)
Project layout:
cmd/server/ # main entry point
internal/db/ # sqlx pool + embedded migrations
internal/services/ # AkteService, FristService, TerminService, CalDAV, ...
internal/handlers/ # HTTP handlers (pages + API)
internal/calc/ # Kostenrechner / Fristenrechner logic
frontend/ # Bun + TSX source; static HTML output to frontend/dist/
docs/ # design docs + this roadmap
Deploy
Push to main → Gitea webhook → Dokploy auto-deploy on mlake.
Project status (April 2026)
Phases A–G, I and J of the KanzlAI integration are shipped: schema, services, Akten, Fristen, Termine + CalDAV, Dashboard, Notizen service + UI (commit 5a9f8e5, 2026-04-17), and instanceable Checklisten (migration 014). Phase H (AI Frist extraction) is deferred pending a reversal of the "no Anthropic API" decision; the Dokumente tab on Akten detail is hidden until that lands. KanzlAI infra retirement (Dokploy shutdown, kanzlai schema drop, Gitea archive) is still pending.
See docs/feature-roadmap.md for the full backlog and docs/design-kanzlai-integration.md for the integration design.