Compte Chatbot ID -4 : pourquoi ne peut-on pas le supprimer via l'interface d'administration et quels sont les contournements possibles ?

Discourse
1

Notes de travail après l’analyse via l’API Admin et le code du noyau Discourse (branche Cursor dans le dépôt hoee).

Objet

Sur l’instance, carte admin : /admin/users/-4/chatbot (Chatbot dans l’admin).

Ce que retourne le JSON admin (capture de vérification)

  • id: -4 (c’est un bot selon les règles du noyau : user_id > 0 uniquement pour les utilisateurs « vivants »)
  • username: Chatbot
  • admin: true
  • moderator: false
  • post_count: 0
  • can_be_deleted: false
  • can_be_anonymized: false

Pourquoi can_be_deleted: false même avec 0 publications

Dans Guardian#can_delete_user?, la suppression est interdite si l’utilisateur cible est admin. Cela ne dépend pas du nombre de publications dans notre cas.

Pourquoi les opérations manuelles via l’UI ou l’API admin ne fonctionnent pas souvent

Pour des opérations comme revoke admin / destroy, sur un id négatif, Guardian#can_administer? échoue : il y a une condition selon laquelle l’identifiant cible doit être positif (obj.id.positive?). Par conséquent, les requêtes vers les routes member du type « comme un username normal » retournent 404, tandis que les requêtes avec le segment -4 peuvent retourner 403 invalid_access, même si l’acteur API est du staff.

Résultat : il est impossible d’utiliser l’API Admin standard (via le même UX que pour les utilisateurs normaux) pour retirer les droits admin ou supprimer le compte du bot — il faut un autre chemin (ci-dessous).

Chemin doux sans suppression de la ligne en base de données

Désactiver le module du bot IA dans les paramètres du site : paramètre ai_bot_enabled (false — le comportement du bot GPT et l’interface associée dans les messages privés / en-tête sont désactivés ; la ligne de l’utilisateur peut rester).

Sur une machine avec le checkout du dépôt hoee et le fichier discourse.env, ajoutez un helper :

  • scripts/discourse-ai-chatbot-operator.sh audit — dump rapide des champs de /admin/users/-4/list.json
  • ai-bot-disable / ai-bot-enable — PUT sur ai_bot_enabled (clés system dans discourse.env, ne pas publier)

Chemin dur : supprimer réellement l’utilisateur

Uniquement sur le serveur d’application Discourse, avec une sauvegarde de la base de données avant les modifications : dans la console Rails, retirez le flag admin de l’enregistrement (par exemple update_columns), puis utilisez UserDestroyer depuis un admin actif avec id > 0 et delete_posts: true si nécessaire. Le bloc de code à copier : scripts/discourse-ai-chatbot-operator.sh rails-destroy-snippet.

Risques : le plugin discourse-ai peut recréer les bots lors des mises à jour ; des messages comme « missing bot user » peuvent apparaître jusqu’à ce que le module répare l’état.

Liens vers le code source upstream

Si nécessaire, vous pouvez fournir une instruction séparée dans les réponses sur « comment vérifier la valeur actuelle de ai_bot_enabled via Admin → Paramètres → plugin discourse-ai » sans utiliser l’API.

2

Mise à jour : compte supprimé

L’opération sur le serveur a été effectuée via rails runner à l’intérieur du conteneur de production app, en tant que utilisateur discourse, et non via l’API Admin (où Guardian ne permet toujours pas d’accéder avec un id négatif) :

  • le flag admin a été retiré de l’utilisateur User.find(-4) via update_columns + reload ;
  • puis UserDestroyer a été lancé par un administrateur actif avec id > 0, en activant l’option delete_posts: true (dans notre cas, aucun post n’existait).

Vérification externe : la requête GET /u/chatbot.json ne retourne plus l’utilisateur, et GET /admin/users/-4/list.json — not_found.

Rappel : lors de la réactivation du module discourse-ai, le plugin peut réactiver le compte du bot si nécessaire.