logaritmisk/biggus-dickus
1
0
Fork 0
Code Issues 17 Pull Requests Actions Packages Projects Releases Wiki Activity

Export a catalogue record as a PDF (offline backup + printable copy) #39

New Issue
Open
opened 2026-06-05 11:46:20 +00:00 by logaritmisk · 0 comments
logaritmisk commented 2026-06-05 11:46:20 +00:00
Owner
Copy Link
Copy Source

Motivation

Curators need a durable, human-readable copy of a catalogue record — both as an
offline backup (store on HDD/DVD/external media, independent of the running
system) and as a printable sheet for a physical archive. A PDF fits both: it's
self-contained, archival, printable, and doesn't require the app to be online.

Scope (v1)

  • Export a single catalogue object (/objects/:id) as a PDF.
  • Out of scope (file as follow-ups): bulk / whole-collection export, scheduled
    backups, ZIP-of-PDFs, embedded images/media (no media subsystem yet).

What the PDF should contain

  • Header: product name (app_name from config — never hardcoded) + object
    number + visibility.
  • Core fields: object_name, object_number, number_of_objects, brief_description,
    current_location, current_owner, recorder, recording_date.
  • Flexible fields: each field definition's localized label + value, with
    term/authority values resolved to human-readable labels (not raw UUIDs)
    and localized_text rendered per language.
  • Footer: generation timestamp; optionally a record id for provenance.
  • Self-contained: no external fetches, so it's a valid offline backup.

Open design questions (resolve in brainstorm before implementing)

  1. Where to render: backend endpoint (e.g. GET /api/admin/objects/{id}/export.pdf
    — server-rendered, deterministic, scriptable for batch backup, reachable from a
    future CLI) vs. frontend (print-styled detail view → browser "Save as PDF" — zero
    new deps, simpler, but less deterministic/automatable). The backup use-case
    leans backend; print is satisfied by either. Likely: backend endpoint + a
    frontend "Export PDF" button that hits it.
  2. PDF library (if backend): Rust options — typst (lib; modern typography),
    genpdf/printpdf (pure-Rust, lower-level), or HTML→PDF via headless Chromium
    (heavy runtime dep — probably avoid given self-host is a first-class target).
  3. Auth/visibility: which capability gates export (likely ViewInternal).
  4. Language: single language with a selector, or a bilingual (sv/en) sheet.
  5. Layout/branding: plain catalogue-card vs. a designed template / letterhead.

Acceptance (v1)

  • A curator can export any object they can view as a well-formed, self-contained PDF
    containing the core + resolved flexible fields, with product name + object number.
  • Reachable from the object detail UI (an "Export PDF" action), and — if backend —
    via a stable endpoint.

Follow-ups (separate issues when this lands)

  • Bulk export (selection / whole collection) as individual PDFs or a combined doc/ZIP.
  • Scheduled/automated backup export.
  • Embed media/images once a media subsystem exists.

Filed at the user's request — a PDF export feature for record backup + physical printing.

## Motivation Curators need a durable, human-readable copy of a catalogue record — both as an **offline backup** (store on HDD/DVD/external media, independent of the running system) and as a **printable sheet** for a physical archive. A PDF fits both: it's self-contained, archival, printable, and doesn't require the app to be online. ## Scope (v1) - Export a **single** catalogue object (`/objects/:id`) as a PDF. - Out of scope (file as follow-ups): bulk / whole-collection export, scheduled backups, ZIP-of-PDFs, embedded images/media (no media subsystem yet). ## What the PDF should contain - **Header:** product name (`app_name` from config — never hardcoded) + object number + visibility. - **Core fields:** object_name, object_number, number_of_objects, brief_description, current_location, current_owner, recorder, recording_date. - **Flexible fields:** each field definition's localized label + value, with `term`/`authority` values **resolved to human-readable labels** (not raw UUIDs) and `localized_text` rendered per language. - **Footer:** generation timestamp; optionally a record id for provenance. - **Self-contained:** no external fetches, so it's a valid offline backup. ## Open design questions (resolve in brainstorm before implementing) 1. **Where to render:** backend endpoint (e.g. `GET /api/admin/objects/{id}/export.pdf` — server-rendered, deterministic, scriptable for batch backup, reachable from a future CLI) vs. frontend (print-styled detail view → browser "Save as PDF" — zero new deps, simpler, but less deterministic/automatable). The *backup* use-case leans backend; *print* is satisfied by either. Likely: backend endpoint + a frontend "Export PDF" button that hits it. 2. **PDF library (if backend):** Rust options — `typst` (lib; modern typography), `genpdf`/`printpdf` (pure-Rust, lower-level), or HTML→PDF via headless Chromium (heavy runtime dep — probably avoid given self-host is a first-class target). 3. **Auth/visibility:** which capability gates export (likely `ViewInternal`). 4. **Language:** single language with a selector, or a bilingual (sv/en) sheet. 5. **Layout/branding:** plain catalogue-card vs. a designed template / letterhead. ## Acceptance (v1) - A curator can export any object they can view as a well-formed, self-contained PDF containing the core + resolved flexible fields, with product name + object number. - Reachable from the object detail UI (an "Export PDF" action), and — if backend — via a stable endpoint. ## Follow-ups (separate issues when this lands) - Bulk export (selection / whole collection) as individual PDFs or a combined doc/ZIP. - Scheduled/automated backup export. - Embed media/images once a media subsystem exists. _Filed at the user's request — a PDF export feature for record backup + physical printing._
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
logaritmisk
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: logaritmisk/biggus-dickus#39
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?