Skip to main content

Module audit

Module audit 

Source
Expand description

The accounting pillar (AAA — docs/archive/AAA_DESIGN.md): a Rocket fairing that records every mutating admin request to the audit_log, so “who did what, when, to what, with what outcome” is observable. Centralizing it in one fairing (rather than a call in each write handler) means no endpoint can forget to log and new endpoints are audited automatically — drift-proof, in the spirit of the symmetry contract.

Structs§

AuditDto
A recorded admin action as exposed over the API/UI — the read view of the audit_log. The timestamp is a formatted string (the model’s at is a chrono NaiveDateTime, not serialized directly — see models::audit).
AuditFairing
Records every mutating request (POST/PUT/PATCH/DELETE) to the audit_log: the resolved crate::frontend::actor (empty if unauthenticated — itself a useful signal), the matched route’s name as the action (Rocket sets it to the handler fn, e.g. delete_corpus), the request path as the target, and the response status as the outcome.
AuditPage
One page of the audit log — the shared shape for the agent endpoint and the human screen.

Functions§

api_audit
The audit log (agent twin of the /admin/audit screen): admin actions, most-recent first, optionally filtered to one actor, paginated — [AUDIT_PAGE_SIZE] rows per page (0-based; has_next flags more history). Token-gated — reading who-did-what is sensitive, so it takes an Actor like the writes it records. 503 if the pool is exhausted.
audit_page
The audit-log screen (GET /admin/audit): the human view of recent admin actions, signed-in admins only (an unauthenticated browser is redirected to the sign-in page). Optional ?actor= and ?limit= mirror the agent endpoint.
routes
The human audit screen (the agent api_audit is mounted via frontend::apidoc).