Audit log
One history of every change made in the admin: who made it, to which record, and what it was before and after.
Audit log keeps one history of every change made in the admin. Each row says who made the change
(a staff member, Starcat or the system), which record it touched, at which Location, and the
values before and after. Every Module with admin changes writes to it, which is why most Modules
need it on. Staff with audit:read read and export the history on the Audit log page. It
doesn't replace a Module's own records of what happened to an order, a booking or a points
balance; those stay with their Modules.
What it handles
- A history nobody can rewrite. Rows can't be edited or deleted, a retried request writes one row instead of two, and keys that look like secrets (a PIN hash, a webhook secret) are dropped before the row is stored. Tested: "Audit log: record"
- Managers who run one Location. A manager tied to one Location sees that Location's rows and
business-wide rows, never another Location's, and asking for another Location is refused
rather than shown empty. Staff without
audit:readare refused. Rows with the same time page without one being repeated or skipped. Tested: "Audit log: history" - An export that matches the screen. Export CSV downloads exactly the rows the filters show, inside the same Location limits, with spreadsheet formulas in the data made harmless. The export is itself recorded, with its filter and row count, and an export by Starcat is recorded as Starcat's. Tested: "Audit log: export" Tested: "Audit log: Starcat operations"
- Keeping history for a set time. A nightly job deletes rows older than the retention window (730 days unless the app sets another) and records that it did. A night with nothing to delete adds no row. Tested: "Audit log: retention"
What you build on top
- Recording your own changes. Every admin change your app adds must write a row here, and a
test in the Module fails when one doesn't. See your app's
AGENTS.md § "Audit". - Who may read it. Admin, Manager and Viewer start with
audit:read. Change that under Settings → Roles & Permissions. - A guided tour. With Tour on, the Audit log page gets a short walkthrough of filtering, opening a change and exporting.
- In code. Your coding agent imports Audit log only through its public API:
index.tsandserver/index.tsinapps/web/src/modules/audit-log/. See Build on a Module.
Limits
- One export holds at most 10,000 rows. Narrow the filters to export more.
- There is no screen for the retention window. It's a stored setting, changed in data or code.
Facts
- Kind: feature Module, can be switched on and off
- Needs: i18n, Identity, Infra, Standard UI
- Needed by: Booking, Branches, Catalog, Customers, Discounts, Finance, Guest ordering, Inventory, Membership, Outbox, POS, Queue, Staff, Storefront, Supply chain, Tour, Website
- Adds to these when they're on: Tour
- Added to by: Nothing
- Off by default for these business types: none
Pages
| Where | Path |
|---|---|
| Admin | /admin/audit-log |
Permissions
Admin holds every key. The other roles listed hold it when the app first gets the Module; after that, roles are yours to change under Settings → Roles & Permissions.
| Permission | What it allows | Organization roles that start with it |
|---|---|---|
audit:read | View audit history exposed by installed Modules. | Admin, Manager, Viewer |
Data
- Tables:
audit_event
Tested workflows
- Audit log: export
- Audit log: history
- Audit log: record
- Audit log: retention
- Audit log: Starcat operations