음, 그거 조금도 싫지 않아요. 드롭다운 버튼의 기본 동작이 '사용자 삭제’이고, 드롭다운을 통해 '사용자 정지’를 선택할 수 있다면 이상적이겠죠. 이렇게 하면 대부분 SSO 환경이 아닌 사용자에게는 추가적인 작업이 필요 없지만, 해당 상황에 있는 사용자는 사용자를 삭제하는 대신 정지할 수 있는 빠른 방법을 갖게 됩니다.
3개의 좋아요
@Roman 이 항목을 목록에 추가할래요? SSO를 사용하는 사이트에는 유용할 것 같네요.
7개의 좋아요
확인해볼게요. 이 사용자들은 승인을 기다리고 있는 건가요?
3개의 좋아요
승인 + 스팸으로 표시된 사용자 삭제.
2개의 좋아요
제가 관리하는 다른 사이트에서는 이런 문제가 발생하지 않는다는 것을 방금 깨달았습니다. 그리고 이것이 최근 삭제된 사용자와 관련된 변경 사항이 있었던 Follow Plugin 
플러그인과 관련이 있을 것 같은 예감이 듭니다. @merefield 어떻게 생각하시나요?
1개의 좋아요
현재로서는 알 수 없습니다. 더 구체적으로 설명해 주실 수 있나요? 로그 증거가 있나요?
브라우저의 네트워크 탭: 해당 404의 URL은 무엇인가요?
현재 플러그인에서 발생하는 유일한 (경미한) 문제는 플러그인을 삭제할 때 관련 알림도 함께 삭제해야 한다는 점입니다(플러그인 OP의 스크립트 참고). 이는 삭제된 사용자와는 무관합니다.
1개의 좋아요
저도 로컬에서 문제를 재현하지 못했습니다. 에러 메시지를 보면 프론트엔드가 존재하지 않는 엔드포인트로 ajax 요청을 보내고 있는 것 같습니다. @bartv 삭제 작업을 수행한 후 브라우저의 네트워크 탭을 공유해 주시겠습니까?
아래와 같은 모습인지 확인하고 싶습니다:
4개의 좋아요
다음에 또 생기면 그렇게 할게 
1개의 좋아요
이 플러그인은 UserDestroyer를 몽키 패치(monkey patch)합니다. 이 메서드는 리뷰 큐에서 삭제 작업을 수행할 때 호출됩니다. 아래 코드는 의심스럽습니다:
만약 following_ids에 잘못된 ID가 포함되어 있다면, User#find가 예외를 발생시키고 사용자는 “404 Not Found” 메시지를 보게 됩니다. 대신 User.find_by(id: ...)를 사용하는 것을 권장합니다.
@bartv님의 사이트에서 이것이 실제로 발생한 것인지 데이터베이스를 직접 확인해 보지 않는 한 단정할 수 없습니다. 따라서 다음에 이런 문제가 발생하면, 해당 플래그가 지정된 사용자의 following_ids를 확인해 보시는 것을 권장합니다.
4개의 좋아요
고맙습니다. 사실이고 매우 유용한 지적입니다.
그래도 여전히 로그와 그 404 URL이 확인되었는지 확인하고 싶습니다.
더 견고하게 만들 수 있는 방법은 아마도 더 많을 것입니다.
4개의 좋아요
푸시 완료: FIX: make code invoked when deleting users more robust · discourse/discourse-follow@b523b3a · GitHub 감사합니다!
3개의 좋아요
Follow 플러그인을 제거했지만 문제가 여전히 남아 있습니다. Rails 로그에서 다음 내용을 확인했습니다:
Started PUT "/review/6793/perform/reject_user_block?version=0" for xx.xx.xx.xx at 2020-09-03 09:45:48 +0000
Processing by ReviewablesController#perform as */*
Parameters: {"version"=>"0", "reviewable_id"=>"6793", "action_id"=>"reject_user_block"}
Job exception: undefined method `strip' for nil:NilClass
Rendering text template
Rendered text template (Duration: 0.0ms | Allocations: 1)
Started GET "/t/global-variables/331828" for xx.xx.xx.xx at 2020-09-03 09:45:48 +0000
Processing by TopicsController#show as HTML
Parameters: {"slug"=>"global-variables", "topic_id"=>"331828"}
Completed 404 Not Found in 292ms (ActiveRecord: 0.0ms | Allocations: 124598)
ActiveRecord::RecordNotFound (Couldn't find all Topics with 'id': (1185852, 1185853, 1186324, 1186929, 1191089) [WHERE ("topics"."deleted_at" IS NULL)] (found 4 results, but was looking for 5).)
lib/plugin/instance.rb:393:in `block in on'
lib/discourse_event.rb:14:in `block in trigger'
lib/discourse_event.rb:13:in `trigger'
app/models/user.rb:1567:in `trigger_user_destroyed_event'
app/models/reviewable.rb:353:in `perform'
app/controllers/reviewables_controller.rb:192:in `perform'
app/controllers/application_controller.rb:340:in `block in with_resolved_locale'
app/controllers/application_controller.rb:340:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:68:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:336:in `call'
config/initializers/008-rack-cors.rb:25:in `call'
config/initializers/100-quiet_logger.rb:23:in `call'
config/initializers/100-silence_logger.rb:31:in `call'
lib/middleware/enforce_hostname.rb:22:in `call'
lib/middleware/request_tracker.rb:176:in `call'
ActiveRecord::RecordNotFound 라인은 리뷰 큐에서 사용자를 삭제하려고 할 때마다 항상 나타나며, 정확히 동일한 토픽 ID와 함께 표시됩니다.
해당 토픽 ID를 확인해 보니, 모두 Events 플러그인을 사용하는 게시물들이었습니다. 그리고 실제로 그중 하나는 삭제된 상태였습니다. 그런데 리뷰 큐의 이 동작이 왜 이러한 항목들을 확인하는지 궁금합니다.
@merefield 다시 도움을 요청하게 되어 죄송합니다 
수정: 플러그인 링크를 변경했습니다
3개의 좋아요
그것은 코어 플러그인입니다.
1개의 좋아요
잠깐, 저는
git clone GitHub - angusmcleod/angus-events-plugin: Allows you to manage events in Discourse · GitHub
을 사용 중인데, 이게 (더 이상) 올바른 리포지토리가 아닌 건가요? (거기서 잘못된 페이지를 링크한 것 같아서 수정 중입니다)
1개의 좋아요
이건 이벤트입니다. @fzngagan 이 부분에 대해 의견이 있으신가요?
3개의 좋아요
클릭하면 올바른 저장소로 연결됩니다.
1개의 좋아요
하하, 아니, 문제는 리뷰 대기열에서 사용자를 삭제하는 것과 관련되어 있어.
4개의 좋아요
이것은 플러그인과 관련이 없으며, 코어 라이브러리 파일입니다.
왜 Events가 관련 있다고 생각하시나요?
3개의 좋아요