Printing, reports, audit logs, and history
Consistent print output, report behavior, and traceability in day-to-day operations.
Help updated for v0.10.21 · 2026-07-13
Printing and reports
Printing in Pluck has two different needs. Documents like reports, estimates, picklists, container lists, and assignment sheets should print with a safe readable inset. Label sheets are handled separately because they must preserve exact physical geometry so Avery-style positions do not drift.
For normal documents, use the shared print dialog to choose the scope, pagination, and print style before opening preview. Printed output should include company branding, a clear title, the selected scope, and a printed timestamp. Report layouts should only show fields relevant to the selected report type so the person reading the paper can understand it without seeing every internal field.
Reports, estimates, picklists, container lists, assignment sheets, and dev print tests keep a document-owned safe inset even if the browser print dialog is set to no margins. Inventory price lists live in the shared inventory report view and show per-type rental pricing for the rate terms enabled in the company profile. Label printing, label templates, partial sheets, and custom fonts have their own Help topics because those workflows use different physical-print rules.
Audit logging
Audit logs are meant to answer “what happened?” without forcing support to inspect raw system data. Good entries name the action, the affected record, and the meaningful before-and-after details.
Use audit logs when you need to understand a change that affected operations, especially company settings, user access, inventory updates, or failed actions. A useful audit row should read like an operational note, not a database dump. If a row is hard to understand, that is usually a sign that the workflow needs better context in the log.
In practice, create/update/delete operations should write audit entries. Audit context should include human-readable identifiers (names, asset IDs, labels). Update audits should include before/after change details when possible. Admin settings can define a retention window so older audit logs can be cleaned up intentionally after a chosen number of days. When the debug widget is enabled, users can send a bug report with what they tried to do, what they expected, and the attached debug context.
Entity history and notes
History and notes are the operational memory of a record. History should capture system events and important changes, while notes should preserve human context that would otherwise be lost between shifts.
Use history when you need the record to explain itself: where an item moved, why it entered maintenance, when it was picked, or what changed during an edit. Use notes for the human side: “customer called,” “case latch is sticky,” or “hold this until the lead confirms.” Both are useful, but they answer different questions.
In practice, entity-level history helps operations understand what changed and when. Notes are append-only and should be scoped to the relevant entity. Operational events (pick/return/maintenance) should appear in relevant histories.