v0.16.0 — Read-only report copy

v0.16.0 — Read-only report copy

Minor release: a new sidebar action, "Export a read-only copy", produces a second HTML file alongside the working one. The export carries settings.readOnly: true, a header banner with the carried version and the export timestamp, the same list and dashboard tables, and a change-log entry on the source so the right revision can be found later. Useful when a steering committee or a client needs the current stand without being handed edit rights.

What this fixes

Before this release, sharing the working file meant sharing the keys to it. The settings lock guarded the configuration; nothing guarded a forwarded file itself. A Berichtskopie (a read-only report copy) was the missing piece — a file the recipient can read, print and re-share but cannot save or change by accident:

<fileStem>-report-<YYYY-MM-DD>.html

Once generated, the export action keeps reaching the export sidebar entry; the rest of the sidebar stays where it always was. The export is a hand-out, not an edit path.

Decisions

• Same build, different payload. Both source and export go through the same buildDocument(reportPayload). No second Vite entry, no second singlefile step — CI cannot drift the two apart, and the runtime stays closed at one entry point.
• settings.readOnly: true on the copy, not a runtime check. Every write surface watches the flag and renders the read-only variant: Save is gone, undo/redo is gone, the Wizard, the AI dock, JSON/CSV import, Merge, bulk-select and the row-edit drawer are all hidden. Reference chips still resolve, but only by switching the entity — opening the referenced record would itself be a write surface.
• Banner above the file bar. The banner is the visible signal. It carries the export label, the version from settings.version and the export timestamp, so a recipient sees the read-only status before they look for a Save button.
• Filename pattern with the export date. <fileStem>-report-<YYYY-MM-DD>.html. A search for report- in the folder lands only on copies; the export never confuses with the source.
• Change-log entry on the source. "Berichtskopie exportiert" (or "Read-only report copy exported" in English) is added to the in-memory audit log at click time and lands on disk with the next save. Without it, no later read can tell which report came from which revision.
• No redact-before-share. The export copies the current file as-is; the read-only flag is the bound, and the recipient can still see every field their file already contained. If something must not be seen, the encryption is the right lever.
• Ctrl+S is a no-op in the copy. Strg+S in the exported file does nothing; save is not only hidden but non-functional. The smoke suite asserts this (step 111).
• i18n strings added in EN and DE. New keys cover sidebar.reportExport, report.banner*, toast.reportExported and log/report.exported in both languages. No new language, no copy-edit of existing strings.
• SCHEMA.views and the saved-views machinery from v0.15.0 still apply. The export dialog does not capture the active view; the views dropdown and the start view behave the same in source and copy.

For existing users

• A new sidebar action ships with the existing exchange group. "Export a read-only copy" sits next to the CSV/JSON import and the existing CSV/JSON export. The hand-out is one click away; no new tab, no new menu.
• The copy carries settings.readOnly: true. The whole UI watches the flag — settings icon, New button, undo/redo, bulk-select and the edit drawer are all hidden in the copy. The recipient sees the data, prints it, re-shares it; they cannot save the file.
• The header banner is the signal. The banner sits above the file bar and shows the export label, the carried version and the export timestamp. Recipients learn what they have from the visible chrome.
• The source keeps an audit-log entry. "Berichtskopie exportiert" (English: "Read-only report copy exported") is added to the in-memory log at click time and is written to disk with the source's next save. The audit log answers "which report came from which revision" without the recipient needing to remember.
• npm test runs the same nine suites; the smoke suite gained eight Berichtskopie steps (104–111). The steps cover button presence, filename pattern, change-log entry, payload write flags, banner text, absence of write surfaces, survival of CSV/JSON export, and Ctrl+S being a no-op in the copy. All green at the tag.

Consciously not included

• No redact-before-share. The copy is the same content the working file carries; the read-only flag is not a redaction. Anything that must not leave the building belongs in the encryption, not the export.
• No second Vite entry. Both source and export go through buildDocument(reportPayload) with the same single-file build. There is no separate bundle to drift.
• No write-then-strip pipeline. settings.readOnly: true is on the copy before any layout is rendered; the export does not piggy-back on save.
• No AI banner in the copy. ai.enabled stays false on the export, so the AI dock is hidden. There is no AI-visible signal that the file is a copy — the banner is the only signal, and that is enough.
• No cross-file sharing of exports. The copy is generated from one source; there is no import/merge between two copies. Two exports of the same source differ only by export date.

Wiki: Handing-Out-a-Read-Only-Copy
Full changelog: v0.15.0...v0.16.0