Организация правильного предмодерирования

[wmakca]

Организация правильного предмодерирования

Суть вопроса:
на сайте есть некоторый набор сервисов (условно: новости, объявления, картинки и т.д.), причем большинство информации приходящей от пользователей должно проходить предмодерацию.

Работать должно так: пользователь отправляет форму, модератор проверяет, выносит вердикт, все счастливы.

Варианты решения:
1. Когда приходит форма от юзера складываем сразу все по подходящим табличкам в базе, заливаем файлы, только не ставим галку опубликовано, в таблицу хистори кладем ид юзера, ид операции;

2. Данные из формы сериализуем/пакуем кладем в хистори рядом с ид юзера, никуда больше не пишем, разбор что и куда идет скриптами модератора, причем исходное сообщение в хистори сохраняется.

Плюсы первого: проще в реализации
Минусы первого: много связей, несекурно(прямая запись в таблицы), много мусора в виде пустых или некорректных сообщений

Плюсы второго: проще контролировать, не возникает проблемы правки существующей и опубликованной записи, нет прямого доступа к бд->секурнее, хранение исходных данных
Минусы второго: достаточно трудоемко в реализации, таблица хистори будет быстро заполняться

 

[Mr_Max]

Раздел теория?
Чет я не вижу ни одного
вопросительного знака в предложениях

Лично я вообще не вижу никакого смысла вставлять данные в основную таблицу до проверки модератором.
1. Зачем вставлять данные в таблицу до модерации, если они (данные) будут удалены?
2. Если важен вопрос производительнсоти - тем-более не нужно напрямую вставлять данные в основную таблицу.

 

[wmakca]

Автор оригинала: Mr_Max
Раздел теория?
Чет я не вижу ни одного
вопросительного знака в предложениях

Лично я вообще не вижу никакого смысла вставлять данные в основную таблицу до проверки модератором.
1. Зачем вставлять данные в таблицу до модерации, если они (данные) будут удалены?
2. Если важен вопрос производительнсоти - тем-более не нужно напрямую вставлять данные в основную таблицу.

1. Если пользователь публикует например 50 объявление, и он "правильный" пользователь, почему бы ему не разрешить сразу опубликовывать инфу?
2. бесспорно

 

[Mr_Max]

почему бы ему не разрешить сразу опубликовывать инфу?

Если важен вопрос производительнсоти

-~{}~ 05.03.08 18:13:

Вставлять в любом случае через временную таблицу.
Вставлять не сразу.
Повесить скрипт на крон, и дергать его каждых 5 минут.
выбирая данные "правильных" юзеров из временой таблиці и инсертя их в основную.

-~{}~ 05.03.08 18:14:

А "неправильные" юзара ждут модерирования.

 

[dr-sm]

Re: Организация правильного предмодерирования

Автор оригинала: wmakca
....
Плюсы первого: проще в реализации
Минусы первого: много связей, несекурно(прямая запись в таблицы), много мусора в виде пустых или некорректных сообщений
....

это надуманные какие-то проблемы

1. каких связей много непонятно, вот если с файлами да еще и с кроном, тогда да много ).
2. что значит несекурно???, запись в таблицы должна быть ВСЕГДА полюбому безопасной. данные чекать/фильтровать надо
3. зачем писать пустые сообщения?

о производительности чего речь вобще?
или ты раcчитываешь на что юзеры по 50 сообщении в секунду вставлять будут, лол?

по моему оптимальный вариант:
вставлять в основную таблицу с pending статусом
модератор после просмотра выставляет статус approved
или удаляет сообщение, добавляя бан поинтов юзеру.
KISS короче )

 

[wmakca]

ну собственно я так и думал, второй надежней и секурней

-~{}~ 05.03.08 20:06:

Автор оригинала: dr-sm
1. каких связей много непонятно, вот если с файлами да еще и с кроном, тогда да много ).

С файлами, и другими таблицами, причем не всегда связи один->много

Автор оригинала: dr-sm
2. что значит несекурно???, запись в таблицы должна быть ВСЕГДА полюбому безопасной. данные чекать/фильтровать надо

Кто-то из умных писал: "система безопасна когда она изолирована", во втором случае мы этого достигаем

Автор оригинала: dr-sm
3. зачем писать пустые сообщения?

Условно пустые, т.е. типа "йцукенг йцукенг", те которые прошли фильтры

Автор оригинала: dr-sm
о производительности чего речь вобще?
или ты раcчитываешь на что юзеры по 50 сообщении в секунду вставлять будут, лол?

1. предполагаемая пиковая нагрузка: до 7.3 сообщений/постов от пользователя в минуту
2. положить в одну таблицу, в любом случае быстрее чем положить в 10 таблиц

а как контролировать повторную правку сообщения, она тоже должна модерироватся, ибо сначала я положил фотку елки под окном, а второй раз уже нецензурную? или кого нить матом послал?

 

[dr-sm]

> С файлами, и другими таблицами, причем не всегда связи один->много
мы видимо разные связи имеем ввиду ).
в первом случае будет достаточно простая, понятная и стабильная подсистема, с единообразным интерфейсом и достаточно простой структурой.
во втором, несколько различных подсистем, имеющих зависимости между собой.

> Кто-то из умных писал: "система безопасна когда она изолирована", во втором случае мы этого достигаем
это да, только следует помнить, что когда система полностью изолирована, она становится неработоспособной ).

> Условно пустые, т.е. типа "йцукенг йцукенг", те которые прошли фильтры
это фильтровать - работа модератора. кандидаты на бан.

> 1. предполагаемая пиковая нагрузка: до 7.3 сообщений/постов от пользователя в минуту
такая нагрузка на производительность селектов не повлияет, имхо.

> 2. положить в одну таблицу, в любом случае быстрее чем положить в 10 таблиц
вот это довольно странно, зачем так много таблиц?
и даже если в первом случае добавление займет в 20 раз больше времени, какая разница? )

> а как контролировать повторную правку сообщения
set message_status = 'pending'

еще, кстати, придется удалять уже отмодерированые сообщения ,)

 

[wmakca]

>вот это довольно странно, зачем так много таблиц?
такая структура базы, много связанных таблиц, конечно не в каждую добавляется что-то при посте, но всеравно.

>еще, кстати, придется удалять уже отмодерированые сообщения ,)

Зачем удалять? Заявки лежат в общей хистори, чтоб можно было откатить до предыдущего состояния.

Как контролировать правку? т.е. пользователь исправил, автоматом скрылось из паблика пока модератор не исправит, а зачем так?

 

[dr-sm]

какой хистори, зачем откатывать, я честно говоря, не понимаю структуры.
если хочешь сделать премодерацию, то исправленые сообщения ,естественно, тоже надо повторно модерировать.

удалять, ну например, из-за нарушения авторских прав и тп, или модератор проглядел что-то.

 

[Groove]

>>>т.е. пользователь исправил, автоматом скрылось из паблика пока модератор не исправит, а зачем так?
шаг 1) пользователь-вредитель пишет правильное сообщение
шаг 2) модератор его пропускает
шаг 3) пользователь-вредитель исправляет уже одобренное сообщение на "йцукен" или

поэтому надо после правки одобренного отправлять на рассмотрение модератору.

Я у себя делаю так:
несколько статусов
- опубликовано
- на рассмотрении модератора
- черновик

Сам пользователь может убрать с публикации недоработанный текст в черновик и подать его на модерацию нажав кнопку "Опубликовать". Если текущий пользователь обладает привилегией без премодерации публиковать (администратор, редактор, или просто безупречная репутация - читай проверенный пользователь) то текст сразу публикуется, в портивном случае получает статус "рассматривается модератором" и появляется в кабинете модератора.

При правке текста ему присваивается статус "черновик". Опять же если текущий пользователь не обладает привилегией без премодерации публиковать тексты, тогда статус так и остается "опубликовано".

Плюс еще для некоторых вещей делал дополнительный статус "запрещено жалобами." Т.е. возле объекта делается кнопка "пожаловаться" и когда набирается критическая масса, например 10 жалоб для коммента, он получает статус "на модерации" и скрывается.

В этом случае вообще можно положиться на социальную фильтрацию. Все зависит от того какие пользователи.

Далее, у меня была проблема с заказными убийствами текстов:
люди собирались в группы и "убивали" тексты конкурентов жалобами. Решил проблему так: тексты закрывались только при достижении критической массы. Т.е. например РОВНО 10 жалоб.
Потом текст скрывался, модератор смотрит - все пучком, открывает его. И уже остальные жалобы идут лесом, они на автомате не "убивают" текст с сайта.

Зато в любой момент можно будет посмотреть связку
объект - количество жалоб
и еще раз вернуться к рассмотрению текста

 

[wmakca]

Автор оригинала: Groove

Я у себя делаю так:
несколько статусов
- опубликовано
- на рассмотрении модератора
- черновик
и еще раз вернуться к рассмотрению текста

ну можно еще добавить статусов разных )

Вопрос немного в другом: складываем все в одну "общую кучу" и это потом разгребаем, или сразу по разным "кучкам" и опять же разгребаем.

 

[Groove]

Простые, конечное объекты (новости) в общую кучу конечно же и возможность добавление своих объектов всем, но публиковать только проверенные.

Сложные объекты (группы новостей), на основе которых другие пользователи будут создавать свои - только доверенным лицам.

В последнее время все таки склоняюсь к такой схеме, которую заканчиваю:
1) сразу публиковать
2) высылать админу сайта уведомление о новом объекте
3) дать возможность жаловаться и самим посетителям производить так называемую "социальную фильтрацию"

Итого: модератор работает только
- в спорных ситуациях по жалобам
- по письмам-уведомлениям при создании объекта
- ну и, естественно, когда сам "наткнется" на нечто из ряда вон выходящее