Вы правы. Ошибка сортировки очереди рецензий возникает из-за того, что в базе данных остаются записи для рецензирования от плагина Akismet после его удаления. Я вижу два возможных решения:
Предоставить задачу Rake для удаления этих записей из базы данных до того, как пользователь решит навсегда удалить плагин.
Применить область действия по умолчанию к классу Reviewable, которая исключает эти записи, если плагин отключен.
Это происходит, пока пост ожидает проверки? Или после его отклонения? Как я уже говорил ранее, загрузка отклонённых постов из очереди автоматически удаляется системой.
Я считаю, что удаление плагинов — редкая ситуация, а механизм области видимости по умолчанию с большей вероятностью приведёт к появлению ошибок.
Будет разумно добавить задачу Rake и разместить её в README в разделе «Удаление» с инструкциями по её выполнению для очистки старых записей. Давайте так и сделаем!
Я пробовал отключить «уведомлять о постх в очереди после», установив значение 0, а также 2000000000. Но я всё ещё получаю множество частых уведомлений «x элементов требуют проверки».
Система отправляет их, потому что в очереди есть ожидающие элементы. Настройка, которую вы изменили, относится к напоминаниям о постах в очереди. Вместо этого установите notify_about_flags_after в 0.
Спасибо, @Roman! Могу подтвердить, что изменение параметра notify_about_flags_after на 0 остановило уведомления
Очень благодарен за добавление rake-задачи для этого! Я переустановлю Akismet и запущу rake-задачу позже сегодня, когда трафик будет на минимуме, а затем обновлю этот пост с результатами.
Похоже, что пользователи, чьи сообщения сразу попадают в очередь на проверку, могут обойти довольно много ограничений по частоте действий при создании тем и сообщений/ответов.
Параметры ограничений по частоте, которые, как кажется, можно обойти:
ограничение на создание тем, ограничение на создание тем новыми пользователями, максимальное количество тем в день, ограничение на создание сообщений, ограничение на создание сообщений новыми пользователями, минимальный интервал между уникальными сообщениями, максимальное количество последовательных ответов.
Параметры для отправки тем и сообщений сразу в очередь на проверку:
«approve post count» (новые пользователи, которым требуется одобрение их первых тем/сообщений), а также индивидуальные параметры категорий «Требовать одобрения модератором всех новых тем» и, скорее всего (я тестировал только вариант для новых тем), «Требовать одобрения модератором всех новых ответов».
Ах, я понял. Спасибо за объяснение. Просто поделюсь своим опытом для справки.
Без принудительного соблюдения лимитов новые пользователи (с одобрением по количеству постов) могут свободно заваливать очередь на модерацию с нулевыми или минимальными ограничениями, в то время как старые доверенные аккаунты ограничены лимитами скорости. Исключение — когда включены опции категории для одобрения всех тем или ответов, тогда и старые доверенные пользователи также не имеют ограничений или имеют минимальные.
Это потребовало бы довольно много работы, но было бы вполне реализуемо одобрять все новые темы, а также начальные темы/посты, созданные новыми пользователями (если они ограничены по скорости). Однако в моём случае это почти невозможно, если пользователи могут заваливать очередь.
В любом случае, большое спасибо за разъяснение, что это сделано намеренно. Это очень помогло. Думаю, я пересмотрю свою стратегию и отключу опции, которые отправляют темы или посты напрямую в очередь на модерацию, оставив её в основном для помеченного контента. Тогда просто модерировать ограниченные по скорости живые публикации постфактум будет работать отлично и будет более динамичным для пользователей.
Я недавно установил параметр сайта «только по приглашениям», и теперь в очереди на проверку, сгенерированной системой для учётной записи пользователя, появился элемент, помеченный как «Требует одобрения».
Странно то, что это существующая учётная запись (ей 4 года) с несколькими сообщениями и уровнем доверия TL2, но она не была активна в последнее время (последнее сообщение было 2 года назад). Однако сегодня пользователь вошёл в систему, после чего была поднята флаг на проверку.
Я ещё не использовал функцию «Одобрить пользователя», и элемент всё ещё находится в очереди на проверку, но, похоже, учётная запись активирована и может использовать форум (как и должно быть).
Кажется, очередь на проверку определяет недавно реактивированные учётные записи как новые и помечает их на проверку, когда установлен параметр «только по приглашениям»?
Редакция: это также произошло сейчас для очень новой учётной записи, созданной всего за несколько дней до включения этого параметра.
Кажется, я видел это раньше, когда вы переключаетесь на режим «только по приглашениям». В некоторых ситуациях Discourse считает, что пользователя нужно утвердить, потому что он получил доступ к сайту через обычную регистрацию. Когда этот переключатель меняется, в его записи не установлен флаг «Утверждён».
Я провёл дополнительное расследование и выяснил, что единственное, что объединяет эти учётные записи (всего четыре), — это то, что все они вошли в систему через один из путей входа по электронной почте (через forgot_password или напрямую через email_login) после того, как был установлен режим invite_only.
Были ли какие-либо размышления о добавлении опции приостановки для тем/постов в очереди, помеченных Akismet? Это предложение поступило на нашем экземпляре, просто потому что у нас используется SSO, поэтому удаление участников редко приносит пользу: участник может просто снова войти в свою учётную запись у основного провайдера и мгновенно получить доступ к форуму, чтобы продолжить свои дела. Приостановка же усложняет им задачу, так как им придётся создать новую учётную запись у провайдера с новым адресом электронной почты.
Я знаю, что это немного странная просьба, но о ней мои модераторы спрашивают довольно часто. Сегодня они вручную обходят систему, чтобы приостановить пользователя, что создаёт для них дополнительную работу, но это того стоит, поскольку пользователь в конечном итоге не готов отказаться от ещё одного адреса электронной почты.