Activity logs

api/views/activity_log_views.py provides the read-only activity log surface for the admin dashboard.

Endpoint family

GET /api/v1/admin/activity-logs/ — paginated, filtered list
GET /api/v1/admin/activity-logs/filter-options/ — dropdown values
GET /api/v1/admin/activity-logs/stats/ — summary banner metrics
GET /api/v1/admin/activity-logs/<uuid:pk>/ — log detail

Access rules

The endpoints require authentication and a manager/admin-capable tenant role. The same permission class also allows platform admins.

Log semantics

This surface is intentionally read-only and excludes archived rows. The implementation only exposes entities that map to visible admin-panel sections, which keeps the UI and audit story aligned.

List endpoint behavior

The list endpoint supports:

pagination
time-window filtering
action type filtering
entity filtering
status filtering
full-text search across action fields and actor identity
safe sort validation

Invalid query parameters return structured errors rather than silently ignoring bad input.

Why this page exists separately

Activity logs are not generic analytics. They are immutable records meant for operational review and admin triage, with a data model and access policy different from the analytics dashboard.

Validation

tests/unit activity-log coverage where filter and permission behavior is asserted
tests/integration admin-dashboard route tests

Scope boundary

For aggregate dashboards that summarize processing behavior rather than audit records, read Analytics. For the underlying audit model and signal wiring, see Architecture overview.