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 기반의 멤버 라우트는 404 오류, -4와 같은 음수 ID는 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 애플리케이션 호스트에서만 가능하며, DB 백업 후 진행: Rails 콘솔에서 사용자 행의 admin 플래그를 해제 (예: update_columns), 이후 실제 사용자 (id > 0)가 UserDestroyer를 호출하여 delete_posts: true 옵션을 적용합니다. 복사 가능한 코드: scripts/discourse-ai-chatbot-operator.sh rails-destroy-snippet.
위험: discourse-ai 플러그인 업데이트 시 봇이 재생성될 수 있으며, 모듈이 상태를 복구할 때까지 missing bot user 메시지가 발생할 수 있음.
upstream 코드 참조
- 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의 현재 값을 확인하는 별도 지시서를 답변에 포함해 드릴 수 있습니다.