Activity log & audit
Every mutation leaves a trail — in the same transaction that made it.
Wiki records an audit row for every mutation — creating a page, changing a role, deleting a space. The row is written inside the same database transaction as the change itself, so the log can never disagree with reality: if the write commits, the audit row commits with it; if it rolls back, so does the record.
What is captured
- The actor (who) — and, when the write was made during an impersonated support session, the instance admin behind them as well. Both identities, never one.
- The action and the affected resource (what).
- Enough context to reconstruct the change.
Destructive actions — including deletes — are captured too, so a removal is never silent.
Two logs, two audiences
The activity log above is per organization, and its members may read it.
Instance-wide administration — banning an account, changing an instance role, starting an impersonation — belongs to no organization and is written to a separate log that only instance admins can open. Organization owners must not see who was banned or impersonated elsewhere on the installation. The one crossover is deliberate: an impersonation is mirrored into the affected person's own activity feed, so being signed in as does not stay invisible to them.
Activity feed
The same data powers an activity feed: a per-organization stream of recent changes, so members can see what's been happening across their spaces and pages.
Why in-transaction matters
Logging after the fact — in a separate write, or from application code that might crash between the change and the log — leaves gaps. Appending the audit row within the transaction makes the trail atomic with the change. That is the guarantee an audit log needs to be trustworthy.