Activity Logs

Activity logs answer the question "what did users do?" Where audit logs record privileged mutations, activity logs record the broader stream of user behaviour: logins, enrolments, quiz attempts, profile edits, and the underlying HTTP requests that drove them.

Where to Find Them

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

End users can also see their own activity from inside their account — see My Activity Logs.

What Each Row Captures

Activity logs are stored in the activity_logs table.

Both actors enriched. The handler (loadUsersForActivityLogs in activity_log_handler.go) collects every distinct user_id and impersonated_by across the page, de-duplicates them, and hits the RBAC database with a single UserAssociationService.GetUsersByIDs call. The returned map then populates the user and impersonated_as blocks on the response — so a page of 50 rows costs one lookup regardless of how many impersonation events are mixed in.

What the UI Shows

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

Click a row to open the detail drawer (activity-log-detail.tsx) which lays out every field, including the impersonator if present and the full metadata JSON in a pretty-printed code block.

Built-in Filters

The toolbar exposes:

The underlying API also supports filtering by action, status_code, start_date/end_date, and user_id — see Filters & Search. A bulk Export button is also present in the toolbar (currently routes through the same generic export plumbing as audit logs).

API

Admin endpoints require audit.read. User endpoints require only a valid JWT — they enforce a WHERE user_id = <caller> filter.

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 acl. is automatically prepended

Impersonation

If an admin acts through Impersonation (read-only) or Masquerade (full access), the resulting activity row carries:

• user_id — the impersonated user (the one whose perspective the actions appeared to be from)
• impersonated_by — the admin who initiated the impersonation

The detail drawer surfaces both clearly, so audit reviewers can always answer "was this really the user, or an admin acting as them?".

See User Impersonation for how impersonation sessions are issued.

How a Row Gets Created

Like audit logs, activity logs are inserted only by the audit-service after consuming an event from the activity.events topic. Publishing services build an ActivityEventPayload and call events.PublishActivityEvent(...). The most common publishers are:

• auth-service — login, logout, register, password change, OAuth events, impersonation transitions
• learning-service — enrolments, course completion, lesson views
• quiz-service — quiz starts, quiz submissions
• Any service using the AuditMiddleware will also publish to the activity stream where appropriate (the middleware is primarily an audit publisher; activity logging stays on the explicit-publish path)

See Event Ingestion for the full payload contract and retry semantics.

Indexes & Query Behaviour

The activity_logs table is indexed for the dominant access patterns:

Troubleshooting