audit-log-browser: 4 of 10 declared sys_audit_log actions have no writer anywhere (login/logout/permission_change/config_change/export/import never materialize)

[huangyiirene]

Symptom

Only CRUD actions ever materialize in sys_audit_log. On a fresh boot:

1. Sign up + sign in a member, then as admin GET /api/v1/data/sys_audit_log?$filter={"action":"login"} → total 0; the only trace is an unattributed update sys_user row (user_id null) diffing last_login_at.
2. PUT /api/settings/branding {"workspace_name":"X"} → 200, then filter {"action":"config_change"} → total 0; the event went to sys_setting_audit with action set instead.

Both reproduced twice. Action census over all 57 rows: {'create':48,'update':7,'delete':2}. The delete half is correct (full old_value, actor, tenant).

Net effect: four enum values (login, logout, permission_change, config_change; also export/import), two shipped list views (auth_events, config_changes) and two dashboard widgets (system_overview.dashboard.ts L89 + L109) are permanently empty. The console makes it worse by listing login/config_change in its own ACTION_OPTIONS — it offers filters for rows the server never writes.

The tamper-proofing half is solid: POST/PATCH/DELETE to sys_audit_log all 405 OBJECT_API_METHOD_NOT_ALLOWED, list total unchanged.

Root cause

Located by the run. packages/plugins/plugin-audit/src/audit-writers.ts subscribes only to the ObjectQL wildcard before*/after* CRUD lifecycle events, so it can emit create/update/delete/restore and nothing else. A repo-wide search finds no writer for login, logout, permission_change, config_change, export or import, though all are declared in the action enum of sys-audit-log.object.ts. Settings writes are audited by settings-service-plugin.ts:315 into sys_setting_audit, never sys_audit_log, while settings-service.types.ts:16 documents the service as "Emit sys_audit_log rows for every successful write."

Confirmed on origin/main: audit-writers.ts docblock still states it subscribes to the before*/after* lifecycle; settings-service-plugin.ts still inserts into sys_setting_audit (~L320) while settings-service.types.ts:16 still carries the contradicting doc line.

Reproduction

1. Fresh boot; sign up + sign in a member.
2. As admin GET /api/v1/data/sys_audit_log?$filter={"action":"login"} → total 0.
3. PUT /api/settings/branding {"workspace_name":"X"} → 200; filter {"action":"config_change"} → total 0 (the row is in sys_setting_audit, action set).

Suggested fix

Either add writers for the declared non-CRUD actions (auth, permission, config, export/import) into sys_audit_log, or reconcile the declared enum, the two list views, the two widgets, and the console ACTION_OPTIONS with what is actually written — and reconcile settings-service.types.ts:16's contract with the sys_setting_audit destination.

Source

Extracted from the QA run #7637 (framework 92f26f7, console 09987b680).

[os-help]

PM review (domain:identity seat, #6022, session session_01BVc1ekPpi6yaWywAUhfzfd): pm:queue → needs-user-decision. This card carries a genuine product fork that dispatching would have to guess, and the two directions diverge structurally:

(A) Build the writers. Add sys_audit_log writers for the six declared non-CRUD actions: login/logout (plugin-auth session lifecycle), permission_change (plugin-security grant/binding writes), config_change (settings service — today it writes sys_setting_audit with action set while its own types file promises sys_audit_log rows), export/import (data plane). This is multi-package feature construction adjacent to the #1883 立项位 (audit/permission lifecycle build-out), not a bug-shaped fix; done piecemeal it risks landing six small event taps with six different shapes.

(B) Shrink the declaration. Reconcile the action enum, the two shipped list views (auth_events, config_changes), the two system_overview dashboard widgets, and the console's ACTION_OPTIONS (objectui — cross-repo) down to what is actually written, and fix the settings-service.types.ts:16 contract line to name sys_setting_audit. This retires shipped-but-empty surface — cheaper, but it changes the platform's audit-compliance story (an auditor reading the enum today believes login events are captured).

Undisputed either way (could be carved out, but the seat recommends against a rider): the settings-service.types.ts:16 doc line is factually wrong today and stays wrong under (A) until a config_change writer exists.

Seat recommendation: (A), staged — login/logout and config_change first (both have single, concrete emission points already located: the auth session hooks and settings-service-plugin.ts:315), with permission_change/export/import as follow-up cards; (B)'s console/view shrink then never happens and the enum becomes true over two waves. But whether the platform promises non-CRUD audit coverage in v17 is a product call, not a lane call.

Deciding question for the maintainer: build (A) — staged or all-at-once — or shrink (B)? Once ruled, the execution card(s) queue in this lane.

---

Generated by Claude Code

[huangyiirene]

Maintainer ruling — 2026-08-12

裁定:两半 —— 便宜的 writer 补上,没有 feature 的枚举值退役。

要点:

• 补 writer(3 个):login / logout(auth 事件已有钩点,顺带解决那条 user_id null 的未归因 last_login_at diff 行)+ config_change(settings 服务已在审计、只是写进了 sys_setting_audit —— 双写或改道 sys_audit_log,实现时一并解决 settings-service.types.ts:16 文档契约与实际去向的矛盾,以实现定契约)。
• 退役(3 个):export / import(无此 feature)与 permission_change(权限对象的写入已以 create/update 行入账,语义重复行不再造)从 enum、两个 list view、两个 dashboard widget、console ACTION_OPTIONS 中一并摘除;按 ADR-0087 登记退役。
• 原则记录:空 widget + 永远查不到东西的过滤器是可见产品缺陷;审计面宁窄勿谎。
• 防篡改半边(405)已验证良好,不碰。

裁定人:维护者 huangyiirene(2026-08-12,接受 PM 综合分析后批准);由 PM 会话 session_01GZKbx4xyF7U5WXj6ch49BM 代笔落卡。转 pm:queue。

---

Generated by Claude Code