2026-08-10 監査ログの閲覧(Issue #34)
- 課題:
application_eventsは #21 で状態更新と同一トランザクションになり、#20 で再試行のたびに失敗が残るようになったが、これを読む手段がアプリになかった。/adminが出すのは現在の状態と、#19 で入れた field ごとの最新の理由1件だけで、「1回目はガス不足、2回目はnonce競合」といった経緯を確認するにはDBへ直接繋ぐしかなかった。Runbookは失敗の再試行について「経緯がアプリ内に揃うため、運用ログ側に経緯を書き写す必要はない」としており、その前提が読む画面のないことで実質満たされていなかった。
決定
1. 申請ごとの履歴を /admin の行内に折りたたみで出す(案A)
/admin/events のような全件一覧(案B)は作らない。
- 運営の実際の問いは「この申請で何があったか」であることが多く、申請の行から辿れるほうが操作と近い。
- 全件一覧は件数が増えたときのページングと絞り込みが要る。#17 に「申請一覧の検索・絞り込み」が候補として残っているので、必要になった時点でまとめて設計するほうがよい。
- 折りたたみは
<details>/<summary>で実装し、状態を持たない。開閉のためだけにクライアント状態を増やさない。
2. 追加のDB問い合わせをしない
app/admin/page.tsx は #19 で既に一覧の全申請分の listEvents を1回で呼んでいる。同じ結果から eventsByApplication で申請IDごとに束ねるだけなので、問い合わせは増えない。
latestReasonsByApplication/latestTxIdsByApplicationと違い、eventsByApplicationは理由や tx hash を持たない遷移も落とさない。承認のような記録の薄い操作も経緯の一部であるため。
3. field ごとの最新1件の表示は残す
履歴を出したので冗長にも見えるが、両方を残す。
- 上段の理由・tx hash は畳んだ状態でも見える。運営が一覧を流し見るときに必要なのはこちら。
- 履歴は「開いて追う」もので、読み手の目的が違う。
4. 実行者は短縮表示にする
管理者の表示名を持っていないため、actor_address を 0x1111…11ab の形に短縮し、完全な値は title 属性で補う。短縮は先頭6文字と末尾4文字を残し、別々の管理者を見分けられるようにする。
ラベルと短縮は lib/applicationEventLabels.ts に置いた。既存の lib/applicationLabels.ts は申請者向けの文言で読み手が違うため、同じファイルへ混ぜない。
含めなかったもの
- 監査ログの編集・削除(追記のみの記録として扱う)
- CSVエクスポート
- 申請者側への履歴表示
- 運用ログのアプリ内移行(#17 の別候補)
- 表示範囲の制限。
reasonに運営内部の判断が入る可能性は #34 で論点として挙げたが、現状/admin自体がrequireAdminで保護されており、履歴に管理者以外は到達しない。