Audit Logs

Audit logs answer the question "who changed what, and what did the data look like before and after?" Every mutation performed by an admin, instructor, or system actor is captured here with the context needed to reconstruct what happened.

Where to Find Them

Sign in as an admin with audit.read permission and go to Admin → Audit → Audit Logs (/admin/audit-logs).

What Each Row Captures

Every audit log row stores the actor, the resource, the operation, and (when available) the data on either side of the change.

Actor enrichment. actor_id is stored as a bare UUID. After the page is fetched, loadActorsForAuditLogs (audit-service/api/handlers/audit_log_handler.go) collects every non-nil ActorID across the result set and issues a single UserAssociationService.GetUsersByIDs call to the RBAC database — so a page of 50 rows costs one lookup. Matches are attached to each row as actor (name, email, avatar). Rows whose actor was hard-deleted from edushade_auth still surface; only the actor block stays empty.

What the UI Shows

The list view (src/components/admin/audit/audit-logs-table.tsx) renders these columns:

Click any row to open the detail drawer (audit-log-detail.tsx) which expands every field — including the full before_value, after_value, and metadata JSON blocks pretty-printed inside scrollable code panels.

Built-in Filters

The toolbar exposes three quick filters (the underlying API supports more — see Filters & Search):

These dropdowns are a curated UI subset, not an exhaustive list of what the backend emits. Services publish other values — for example tag_association, category_association, subscription_plan, purchase, refund, installment_payment, manual_payment, scholarship, file, multipart_upload, media, directory, and the generic api_call produced by Audit Middleware. Modules also include misc, migration, and booking. The API's resource_types[] and modules[] query params accept any string, so you can filter by those values directly even when the UI dropdown does not list them — see Filters & Search.

A bulk Export button is available in the toolbar — see Export.

API

All three require a valid JWT and the audit.read permission. All three are scoped to the caller's tenant by audit-service/middlewares — the tenant ID comes from the request context and is used as the leading WHERE clause.

Pagination Defaults

• Default page size: 50 rows
• Default sort: created_at DESC
• sort_by accepts any column name; if it doesn't already contain a ., the alias al. is automatically prepended

See API Reference for the full request/response shape.

How a Row Gets Created

Audit log rows are never inserted by application code directly. They are always the product of an event published to the audit.events topic and persisted by the AuditEventSubscriber in the audit-service. There are two main publishing paths:

1. Explicit publishes — A handler builds an AuditEventPayload and calls events.PublishAuditEvent(...) after a mutation succeeds. Used when you want full control over before_value, after_value, and description.
2. Auto-publishes via middleware — Mounting events.AuditMiddleware(publisher, "<module>") on an admin route group automatically publishes a row for every successful POST/PUT/PATCH/DELETE. Resource is recorded as api_call and endpoint goes into both resource_id and metadata.endpoint.

See Event Ingestion for the payload contract and Audit Middleware for the drop-in.

Indexes & Query Behaviour

The audit_logs table is indexed for the access patterns you actually use:

Filtering by a non-tenant column on its own (without a date range) on a multi-tenant table can fall back to a sequential scan; the UI never does this because tenant scoping is mandatory.

Troubleshooting