brewDB Table Audit Log

Every table in brewDB keeps an audit trail of the actions taken against it. Open it from a table’s context menu (“View audits…”) to see who did what, when, and — for DDL-changing entries — the actual SQL that ran. The legacy application had no query interface at all, so this view has no legacy equivalent.

What Gets Audited

The audit log covers the full range of actions a table can be subject to: row-level operations like inserts, deletes, updates, and queries; schema-changing DDL such as adding columns, indexes, constraints, or foreign keys; and administrative actions like ACL changes, renames, and retention or compression policy changes.

You can filter the grid by action (multi-select, with search), by a time range (24h, 7d, 30d, or all-time), by source (UI, gRPC, or Audits), and by a metadata key/value pair. Depending on your permissions, the grid shows audits for every user against the table or only your own — a banner above the grid tells you which scope you’re looking at.

Reading an Audit Entry

The grid has five columns:

• When — the timestamp of the action.
• Action — the audit action, e.g. INSERT_INTO_DB or ADD_DB_INDEXES.
• Source — where the action originated: the brewDB UI, a gRPC caller, or the audit system itself.
• Profile — the user who performed the action, shown with their avatar and display name once resolved.
• Metadata — a summary of the entry’s metadata (e.g. field count for a JSON object).

Selecting a row opens a detail panel with the entry’s action, timestamp, subject, and its full metadata pretty-printed and syntax-highlighted as JSON.

DDL Entries

When an entry’s metadata carries a sql field — as DDL-changing entries do — the detail panel shows a View SQL button. Clicking it opens the formatted, syntax-highlighted SQL statement that actually ran against the table, with a copy-to-clipboard action.