Audit logging becomes a runtime admin setting — enable after deployment, persists via state-in-backend #186

New issue

Closed

opened 2026-08-10 20:19:14 +00:00 by Cordy · 1 comment

Cordy commented

2026-08-10 20:19:14 +00:00

Owner

Dogfood note (Nikola, following #173): audit logging should be enableable after initial deployment, from the admin panel like other settings, and persist through deployments/updates.

This is design-consistent, not an exception. The v0.6 config/state line says: config = how to find and unlock your data; state = everything else, living with the data. The audit switch is instance policy — exactly the class peeringEnabled is in — so it belongs in the settings store, which since v0.6 lives encrypted in the backend and survives any redeploy by construction. The audit directory (audit.path, filesystem layout) stays config, like peering.stagingDir.

Implementation, mirroring the #134 peering pattern:

The audit logger is constructed at every boot (default path unless configured) instead of only when audit.enabled — the decorator is always in the stack.
Append is gated on a runtime closure reading the settings store (auditEnabled), so flipping the toggle takes effect without a restart and a disabled logger writes nothing.
Settings store gains auditEnabled; the admin Settings dialog gains the toggle (next to retention/auto-purge, where the audit button already lives), i18n ×4.
Config compatibility: audit.enabled: true in the config acts as the initial value on first boot (adopted into settings once), so existing declarative deployments keep working; after that the runtime setting is authoritative. Precedence stated in the config comment.
#173's "not enabled" panel message becomes actionable for admins: "Audit logging is off — enable it here" linking the toggle.
Honest note in the docs: enabling audit starts the record from that moment; nothing is retroactive.

Also resolves the open question on #173 (whether to edit the dogfood config secret): with this, no secret edit needed — the toggle does it.

Dogfood note (Nikola, following #173): audit logging should be enableable *after* initial deployment, from the admin panel like other settings, and persist through deployments/updates. **This is design-consistent, not an exception.** The v0.6 config/state line says: config = how to find and unlock your data; state = everything else, living with the data. The audit *switch* is instance policy — exactly the class `peeringEnabled` is in — so it belongs in the settings store, which since v0.6 lives encrypted in the backend and survives any redeploy by construction. The audit *directory* (`audit.path`, filesystem layout) stays config, like `peering.stagingDir`. **Implementation, mirroring the #134 peering pattern:** 1. The audit logger is **constructed at every boot** (default path unless configured) instead of only when `audit.enabled` — the decorator is always in the stack. 2. `Append` is gated on a runtime closure reading the settings store (`auditEnabled`), so flipping the toggle takes effect without a restart and a disabled logger writes nothing. 3. Settings store gains `auditEnabled`; the admin Settings dialog gains the toggle (next to retention/auto-purge, where the audit button already lives), i18n ×4. 4. Config compatibility: `audit.enabled: true` in the config acts as the *initial* value on first boot (adopted into settings once), so existing declarative deployments keep working; after that the runtime setting is authoritative. Precedence stated in the config comment. 5. #173's "not enabled" panel message becomes actionable for admins: "Audit logging is off — enable it here" linking the toggle. 6. Honest note in the docs: enabling audit starts the record *from that moment*; nothing is retroactive. Also resolves the open question on #173 (whether to edit the dogfood config secret): with this, no secret edit needed — the toggle does it.

Cordy added this to the v0.7 — Closed beta (dogfood + hardening) milestone

2026-08-10 20:19:14 +00:00

Cordy commented

2026-08-12 21:14:37 +00:00

Author

Owner

Triage: autonomous (next build). Same pattern as peering-enable (#123) and the v0.6.15 quota settings: add auditEnabled to the settings store, have the audit sink read it live so the audit admin panel appears/disappears without a restart, add a Settings toggle; persists via state-in-backend. Config audit.enabled stays the seed/default. First step: settings field + main.go wiring + Settings toggle + feature-detect on the frontend.

**Triage: autonomous** (next build). Same pattern as peering-enable (#123) and the v0.6.15 quota settings: add `auditEnabled` to the settings store, have the audit sink read it live so the audit admin panel appears/disappears without a restart, add a Settings toggle; persists via state-in-backend. Config `audit.enabled` stays the seed/default. First step: settings field + `main.go` wiring + Settings toggle + feature-detect on the frontend.

Cordy referenced this issue from a commit

2026-08-12 21:21:30 +00:00

ci: v0.6.16 edit script (#186 audit runtime toggle)

Cordy referenced this issue from a commit

2026-08-12 21:21:58 +00:00

ci: v0.6.16 ship workflow (#186)