Я хотел бы использовать вебхук для удаления спамеров из нашей центральной базы данных, когда я удаляю их в очереди модерации, но событие не срабатывает, когда я настраиваю вебхук таким образом. Должно ли оно срабатывать, или я неправильно понимаю часть «…и когда его статус обновляется»?
Вызывается ли вебхук «удаление пользователя»?
Да. К сожалению, событие удаления не передается, и я хочу действовать только тогда, когда пользователь удален и заблокирован по IP.
Я хотел бы запросить возможность автоматического скрытия изображений по умолчанию, в частности для постов, помеченных пользователями уровня TL0. Хотя необходимость просматривать неподобающие изображения и принимать меры в соответствии со стандартами каждого сообщества сохраняется, было бы полезно скрывать изображения для тех, кто работает в офисе или из дома с детьми поблизости (как это часто бывает у меня).
API для «обхода» требования оценки в очереди на проверку ссылка всё ещё недостаточна в течение длительного времени, так как оценка периодически пересчитывается. Если очередь не обрабатывается в момент создания элемента для проверки, «принудительно» помеченный элемент может исчезнуть из списков с высоким фильтром до того, как модераторы смогут его проверить.
Возможно, стоит добавить в модель Reviewable булево поле force-review, которое будет учитываться в запросе для расчёта оценки здесь.
Изображения пользователей TL0 по умолчанию размыты. Это можно отключить через настройку blur_tl0_flagged_posts_media.
Это также реализовано. Когда флаг force_review установлен в значение true, ожидающие проверки элементы будут отображаться в очереди, даже если они не достигают минимального порога видимости по баллам.
@Roman — Извините, я ещё не вернулся к этому вопросу. Если это всё ещё может быть полезно, у меня есть логи, из которых я извёл некоторые записи (очищенные от идентифицирующей информации). Сейчас работает версия 2.6.0beta3. Все ошибки “integer out of range” связаны с записями одного типа.
2020-11-26 06:02:13.009 UTC [25408] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.009 UTC [25408] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 1533, '{"topic_title":"{private info removed}","original_post_id":17769856,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.008758', '2020-11-26 06:02:13.008758', 1333533, 4) RETURNING "id"
2020-11-26 06:02:13.038 UTC [29728] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.038 UTC [29728] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 1533, '{"topic_title":"{private info removed}","original_post_id":17725230,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.037676', '2020-11-26 06:02:13.037676', 1313715, 38) RETURNING "id"
2020-11-26 06:02:13.052 UTC [27579] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.052 UTC [27579] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 1533, '{"topic_title":"{private info removed}","original_post_id":17713480,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.051222', '2020-11-26 06:02:13.051222', 1314869, 237) RETURNING "id"
2020-11-26 06:02:13.149 UTC [27554] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.149 UTC [27554] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 180552, '{"topic_title":"{private info removed}","original_post_id":17713479,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.148264', '2020-11-26 06:02:13.148264', 1313773, 48) RETURNING "id"
2020-11-26 06:02:13.170 UTC [28970] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.170 UTC [28970] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 46891, '{"topic_title":"{private info removed}","original_post_id":17760644,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.168959', '2020-11-26 06:02:13.168959', 1328670, 25) RETURNING "id"
Также было бы полезно иметь возможность просматривать список рассмотренных задач, отфильтрованный по модератору, который обработал флаги. Фильтр «назначено» при просмотре ранее обработанных флагов семантически очень похож на поиск по фильтру «обработано», но это не одно и то же.
Должен ли фильтр «назначено» для разрешённых флагов/задач показывать того, кто обработал флаги, или это может быть отдельный фильтр?
Я думаю, это отличное предложение, @Roman — можешь добавить его в свой список?
Я использую вебхук и API для добавления новых тем в очередь проверки, чтобы модераторы могли проверить новую тему на соответствие правилам. В настоящее время я помечаю первый пост в новой теме с помощью API. Это работает, но при просмотре истории администратора пользователя это выглядит нехорошо. Есть ли другой способ, который не создаст у пользователя плохого впечатления?
Есть ли причина, по которой вы не можете использовать «одобрять новые темы только при определенном уровне доверия»? Эта функция уже встроена в Discourse.
Я согласен, что это сработает для многих случаев использования. Нам требуются теги из нескольких групп тегов, что не поддерживается в Discourse. Мы хотим разрешить создание новой темы без одобрения, но убедиться, что теги верны, по мере возможности.
Я предполагаю, что предлагаю способ добавления произвольных элементов в очередь проверки. В настоящее время поддерживаются три типа: помеченный пост, поставленный в очередь пост и пользователь. Мы используем помеченный пост, так как он ближе всего к тому, что нам нужно, но было бы удобно добавить элемент «Проверить теги» в очередь проверки, даже если мы сможем делать это только через API.
Простого способа сделать то, что вы хотите, не существует.
Лучший вариант — создать плагин, который добавит новый тип рецензируемого контента, а также какой-либо endpoint для их создания.
Есть ли способ отключить это диалоговое окно? Мы почти всегда отклоняем спамеров, а это добавляет лишний клик в наш рабочий процесс:
Я уже писал об этой же проблеме здесь: Account rejection email - #11 by simon.
Есть ли способ добавить объект типа «User» в очередь на проверку через API? Или это доступно только коду, создающему нового пользователя?
Мой сценарий использования заключается в том, что я хочу, чтобы модераторы проверяли любые обновления пользователей, чтобы убедиться, что они соответствуют правилам. Поэтому у меня есть вебхук user_updated, и я хочу поместить обновлённого пользователя в очередь на проверку.
Я смог методом обратного инжиниринга выяснить, как пометить пост (/post_actions…), поскольку могу вручную пометить пост и отслеживать сетевой трафик, но не знаю, как сделать то же самое для пользователя. Думаю, это что-то вроде /user_actions…
В настоящее время выполнить это через API невозможно. Думаю, вам придется добавить плагин, который перехватывает обновление пользователя и создает объект для проверки.
2 сообщения были перенесены в новую тему: Ответы на одобрение сообщений
Привет! Это конструктивная критика очереди модерации.
Я знаю, что были внесены улучшения в кнопки «Отклонить / Одобрить», чтобы сделать их менее двусмысленными («Я одобряю пост или я одобряю жалобу?»). Однако у этих статусов всё ещё есть двойное значение, что делает просмотр списка уже обработанных элементов довольно запутанным для меня, поскольку фильтр «Статус» и статус в правом верхнем углу не имеют ясного смысла. Вот несколько примеров:
Одобрена жалоба на пост, помеченный как «печатает слишком быстро» → Пост одобрен → Статус: Одобрено
Одобрена жалоба на неуместный пост → Пост отклонён → Статус: Одобрено
Отклонён пользователь за спам в профиле → Пользователь заблокирован → Статус: Отклонено
Отклонена жалоба на пост → Пост остаётся → Статус: Отклонено
Похоже, что необходимо различать следующие статусы, и некоторые элементы могут иметь оба:
- Пользователь/пост одобрен
- Пользователь/пост отклонён
--- - Модерация одобрена
- Модерация отклонена
Ещё одно предложение по улучшению в случае спамеров в профилях пользователей: я бы хотел видеть возможность удалить учётную запись и заблокировать email, но не IP-адрес, поскольку они часто используют общие диапазоны IP, которые также могут использоваться легитимными пользователями.





