Admin API および Discourse カーネルコードの解析後の作業メモ(hoee リポジトリの Cursor ブランチ)。
オブジェクト
インスタンス上の管理者カード: /admin/users/-4/chatbot (管理者画面の Chatbot)。
管理者JSONが返す内容(検証スナップショット)
id: -4(カーネルのルールではボット。user_id > 0は「実在するユーザー」のみ)username: Chatbotadmin: truemoderator: falsepost_count: 0can_be_deleted: falsecan_be_anonymized: false
なぜ can_be_deleted: false なのか(投稿数が0の場合)
Guardian#can_delete_user? では、管理者であるユーザーの削除は禁止されています。このケースでは投稿数とは無関係です。
なぜ UI または管理者 HTTP で「できない」のか
revoke admin / destroy などの操作では、負の id に対して Guardian#can_administer? が通らない。その条件として、対象の ID が正の値である(obj.id.positive?)必要があります。したがって、通常の username による member ルートへのアクセスは 404 となり、-4 などのセグメントでは、API アクターがスタッフであっても 403 invalid_access が返る。
結論: 通常の Admin API による管理者権限の解除やアカウント削除は、ユーザー同様の UX では不可能。別の手段が必要(以下参照)。
ソフトウェア的アプローチ(DB のレコード削除なし)
サイトの設定で AI ボットモジュールを無効化: パラメータ ai_bot_enabled を false に設定(GPT ボットおよび関連 UI の動作が抑制される。ユーザーのレコードは残る可能性あり)。
hoee リポジトリの checkout および discourse.env ファイルがある環境で、以下ヘルパーを追加:
scripts/discourse-ai-chatbot-operator.sh audit-/admin/users/-4/list.jsonのフィールドを簡潔にダンプai-bot-disable/ai-bot-enable-ai_bot_enabledへの PUT リクエスト(discourse.envの system キーを使用。公開しないでください)
ハードウェア的アプローチ:ユーザーを実際に削除
Discourse アプリケーションのホスト上で、DB のスナップショットを取ってから、Rails コンソールで admin フラグを解除(例: update_columns)。その後、実在する管理者(id > 0)で UserDestroyer を実行し、必要に応じて delete_posts: true を指定。コピー用のスクリプト: scripts/discourse-ai-chatbot-operator.sh rails-destroy-snippet。
リスク: discourse-ai プラグインの更新時にボットが再作成される可能性あり。また、モジュールが状態を修復するまで「bot user missing」のメッセージが出る可能性がある。
上流コードの参照リンク
- discourse/discourse
app/models/user.rb-human?/ 負の ID - discourse/discourse
lib/guardian.rb-can_administer? - discourse/discourse
lib/guardian/user_guardian.rb-can_delete_user?
必要であれば、別途「Admin → 設定 → discourse-ai プラグイン」で ai_bot_enabled の現在値を確認する手順を追加できます(API なし)