編集画面から値を直接変えられれば、店舗情報の反映は簡単になる。しかし誤った値を保存した後に以前の内容を探せなければ、管理者は更新を見張り続ける必要がある。利用者へ編集を開くには、入力道具に加えて変更を確認し戻す方法も必要だ。

GammaではOAuthログインと役割別の権限を導入し、要求内容をuserTicketへ保存するようにした。アカウントと提出内容を一緒に調べられる形にし、参加を広げる準備をする変更である。

直接更新と変更履歴の必要性

PocketBase SDKで更新することで手作業は減ったが、誤った変更を復元する機能はなかった。例えば営業時間を間違えて入力した場合、現在値だけでは以前に何を送ったか分からない。この状態で編集者を増やせば確認も増える。

そこで、誰が提出し、どの値を送ったかを一緒に保存することにした。過去の要求を読めれば、問題発見後に内容を確認し、再適用する資料として使える。

flowchart TD
    accTitle: アカウントと編集の入口
    accDescr: アカウントを確認し役割を区別してから専用APIで編集する。
    A["OAuthログイン"] --> B
    B["役割の確認"] --> C
    C["領域別の編集API"]

OAuthログインと役割別の編集権限

OAuthは外部のログイン提供者を利用してアカウントを確認する方式である。文書編集ではログインを必須にし、最高管理者、管理者、会員の役割を区別した。本人を確認しただけで管理者作業まで認めるものではない。

更新は文書の項目別APIへ移した。APIは画面からサーバーへ変更を要求する窓口である。汎用PUTで直接上書きする経路を止め、要求者の確認と提出内容の保存を編集の経路へ組み込んだ。

flowchart TD
    accTitle: リクエストを残す復元
    accDescr: 保存した過去の要求を新規リクエストとして同じ経路へ提出する。
    A["リクエストJSONを保管"] --> B
    B["過去の要求を選択"] --> C
    C["新規リクエストとして再登録"] --> D
    D["同じ編集経路で反映"]

要求の保存と以前の内容の再適用

編集APIが受け取るJSONをuserTicketへ保存する。JSONは提出した項目と値を表す形式だ。元の入力を残すことで、現在の文書と比べたり復元用の要求へ使ったりできる。

復元では過去のチケットの値を選び、新しい要求として同じ編集処理へ送る。元の記録は消さず、復元も新規提出として残す。特定文書の入力を再適用する機能であり、サーバー全体を過去へ戻すバックアップ復旧ではない。

flowchart TD
    accTitle: 残している保護策
    accDescr: 履歴とともにクールダウンと敏感な編集の承認を適用する。
    A["編集リクエスト"] --> B
    B["作成クールダウンと履歴"] --> C
    C["敏感な変更の管理者承認"] --> D
    D["公開へ反映"]

連続送信と重要な変更の管理

チケット作成にはクールダウンを設ける。次の提出まで待機時間を置き、連続要求やスパムを制限する方法だ。写真、新規店舗、閉店の変更は、引き続き管理者の承認後に公開する。

作成者と提出値を探し、過去の要求を反映し直せるようになった。ただし保存対象はまだ生のJSONであり、検証と形式の統一は改善する必要がある。日常の訂正の使いやすさと、公開前の確認が必要な項目を分けて運用する予定だ。

参考：Musecatエンジニアリング記録。