Expanded audit_logs coverage from "force deletions only" to a wider set
of sensitive admin actions. The Audit Log view's action filter dropdown
picks them up automatically (it queries distinct actions from the table).
New audit actions written:
- user.delete (every delete; metadata includes username, email, force,
and dependent counts when applicable). Replaces user.force_delete for
new entries; old rows remain.
- role.create / role.update / role.delete (in artifacts/api-server/src/
routes/roles.ts). role.update only fires when fields actually change
and records previousName + changes.
- role.permissions.replace / role.permission.add / role.permission.remove
for the PUT /roles/:id/permissions, POST /roles/:id/permissions, and
DELETE /roles/:id/permissions/:permissionId endpoints. Replace records
added[] and removed[] diffs; add/remove records permissionId and
permissionName so the affected permission stays identifiable even if
later renamed/deleted. No-op writes (same permission re-added, replace
with identical set) skip the audit.
- group.create / group.update / group.delete (group.delete replaces
group.force_delete for new entries; metadata always includes force +
counts). group.update records changed fields and added/removed lists
for members, apps, and roles when those collections were touched.
- group.user.add / group.user.remove / group.app.add / group.app.remove
/ group.role.add / group.role.remove for the sub-resource
POST/DELETE /groups/:id/:kind/:targetId endpoints (only when something
actually changed, via .returning() guard).
- auth.issue_reset_link in routes/auth.ts admin issue-reset-link.
- app.create / app.update / app.delete (app.delete replaces
app.force_delete for new entries with force flag in metadata).
app.update only fires when something actually changed and records a
per-field {from, to} diff.
- settings.update with per-field {from, to} diff (covers
registrationOpen and any other UpdateAppSettingsBody field).
Out of scope / deviations:
- "App-permission changes" is in the task description, but no admin
endpoints exist yet to write app_permissions. A separate task ("Let
admins manage which permission an app requires from the UI") will add
them. Filed follow-up #113 to add the audit hooks once those endpoints
exist. Also filed #114 (readable summaries for new actions) and #115
(automated tests for the expanded coverage).
- The pre-existing standalone task "Record an audit trail when a role's
permissions change" was folded into this task at code-review request,
since the same task description called out role permissions. That
separate task is now obsolete.
Verified end-to-end via curl against the running API: every new action
appears in /api/admin/audit-logs and in the actions[] dropdown list,
including all three role.permission* actions.
Riyadh
d16e673b2d