m 70c3f08668 fix(projects-detail, services): empty-list endpoints returned JSON null → tab content blank
m reported /projects/{id} loaded the chrome and tabs but every panel was
empty even with deadlines/appointments/team rows that should render.
Console error: "Cannot read properties of null (reading 'length')" at
projects-detail.js — the Project Detail page expects every list endpoint
to return [] but at least two were returning literal JSON null.

Reproduced via the in-page fetch console:
  /api/projects/{id}/parties   → 200, body: "null"
  /api/projects/{id}/children  → 200, body: "null"
  /api/projects/{id}/deadlines → 200, body: "[…]"   (had data, fine)
  /api/projects/{id}/team      → 200, body: "[…]"   (had data, fine)

Root cause: every list service in internal/services declared its result
as `var rows []models.X` and returned that to the handler, which
encoding/json marshals as `null` when the SELECT returns zero rows
(nil slice, not empty slice). Most endpoints happen to have data so
the bug stayed dormant until t-paliad-038 hit /projects/{id} where
parties + children are commonly empty.

Fix at the source — every list service that JSON-marshals to a client
now initialises `rows := []models.X{}` so the encoder produces `[]`:

  party_service        ListForProjekt
  project_service      List, ListAncestors, BuildTree, GetTree
                       (ListChildren goes through List)
  deadline_service     List + ListForProjekt
  appointment_service  List + ListForProjekt
  note_service         ListForProjekt
  checklist_instance_service  ListForProjekt
  team_service         List
  department_service   List + ListMembers + ListWithMembers

caldav_service was deliberately left alone — its lists are admin-only
debug surfaces, not user-facing tab fillers, and changing them would
mix scopes.

Belt-and-braces on the client too — projects-detail.ts now coerces every
`await resp.json()` for an array endpoint with `?? []` so a future
service regression can't crash the page.

Verified: go build/vet/test clean, bun run build clean.
2026-04-26 01:44:09 +02:00

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: mAi/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), sqlx for DB access
  • Migrations: golang-migrate/migrate/v4 with SQL files embedded via embed.FS; applied at server startup before the HTTP listener binds
  • Database: youpc Supabase Postgres, paliad schema. Office-scoped RLS (paliad.can_see_akte(akte_id)) — see docs/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_Zzyo on 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/migrations/_dev/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 AG, 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.

Description
patholo.de — Patent knowledge sharing platform for HL colleagues
Readme 18 MiB
Languages
Go 50.7%
TypeScript 37.4%
CSS 6.7%
PLpgSQL 4.5%
HTML 0.3%
Other 0.3%