О, меня это совершенно не смущает. Было бы идеально, если бы основным действием кнопки выпадающего списка было «Удалить пользователя», а с помощью выпадающего меню можно было бы выбрать «Приостановить пользователя». Таким образом, предполагая, что большинство установок не используют SSO, для них не добавляется никакой дополнительной работы, но для тех, кто находится в такой ситуации, появляется быстрый способ приостановить пользователя вместо его удаления.
3 лайка
@Roman, хочешь добавить это в свой список? Я считаю, что это будет полезно для сайтов с SSO.
7 лайков
При удалении пользователей из очереди на рецензирование появляется всплывающее окно «404 Not Found»:
(Только что обновились до последней версии, проблема сохраняется)
3 лайка
Я посмотрю. Эти пользователи ожидают одобрения?
3 лайка
Подтверждение и удаление пользователей, отмеченных как спамеры.
2 лайка
Я только что осознал, что также управляю другим сайтом, где такого не происходит, и у меня есть подозрение, что это может быть связано с плагин Follow 
, так как недавно в нём произошли изменения, касающиеся удалённых пользователей. @merefield, что ты думаешь?
1 лайк
На данном этапе не имею представления. Можете уточнить? Есть ли лог-данные?
Вкладка «Сеть» в браузере: какой URL выдаёт ошибку 404?
Единственная (незначительная) проблема с плагином на данный момент (насколько мне известно) заключается в том, что при удалении плагина необходимо также удалить связанные уведомления (скрипт находится в первом сообщении темы плагина). Это не связано с удалёнными пользователями.
1 лайк
Мне также не удалось воспроизвести проблему локально. Сообщение об ошибке наводит на мысль, что фронтенд отправляет AJAX-запрос к несуществующему эндпоинту. @bartv, не могли бы вы поделиться вкладкой «Network» вашего браузера после выполнения действия удаления?Мне бы хотелось узнать, выглядит ли это так:
4 лайка
Сделаю в следующий раз, когда это произойдёт 
1 лайк
Плагин использует monkey-патчинг для UserDestroyer, который вызывается при выполнении действия удаления из очереди рецензий. Это выглядит подозрительно:
Если somehow following_ids содержит некорректный ID, User#find вызовет исключение, и пользователь увидит сообщение “404 Not Found”. Рекомендую использовать User.find_by(id: ...) вместо этого.
Я не могу сказать, произошло ли это на сайте @bartv без проверки базы данных, поэтому в следующий раз, когда это случится, рекомендую проверить following_ids у отмеченного пользователя.
4 лайка
Спасибо. Это верно и очень полезное замечание.
Тем не менее, я всё ещё хотел бы получить логи и подтвердить этот URL с ошибкой 404.
Вероятно, есть ещё больше способов сделать это более надёжным.
4 лайка
Отправлено: FIX: make code invoked when deleting users more robust · discourse/discourse-follow@b523b3a · GitHub спасибо!
3 лайка
Мы объединили PR, чтобы добавить это действие. Подтверждение, подтверждение + удаление и подтверждение + приостановка теперь сгруппированы вместе:
4 лайка
Я удалил плагин 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/discourse-events: Allows you to manage events in Discourse · GitHub
Это не тот репозиторий (больше?) (Кажется, я указал неверную ссылку, исправляю)
1 лайк
Это события. @fzngagan, есть какие-то мысли по этому поводу?
3 лайка
Нажатие на него ведёт к правильному репозиторию.
1 лайк
Ха-ха, нет, речь о проблеме с удалением пользователя из очереди на проверку.
4 лайка
Это не связано с плагином, это файл основной библиотеки.
Почему вы считаете, что здесь задействован Events?
3 лайка