Как избежать одновременного редактирования одних и тех же данных разными людьми?

[DarkLight]

Здравствуйте!

Есть админка для модераторов (модераторов несколько человек). Модерация проходит в несколько ступеней, на каждой идёт смена статуса данных, то есть нужно несколько раз через отрезок времени сменить статус у модерируемых данных в порядке прохождения модерации. Отрезки времени зависят от юзера чьи данные модерируются, он может подождать для подачи заяки для повышения статуса, а может захотеть сразу дойти до финального статуса.

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

Есть очевидное решение проблемы:

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

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

Скорость прохождения всех этапов модерации в приоритете. Не желательно привязывать данные к какому либо одному модеру, даже временно.

Не знаю понятно ли объяснил))) Буду рад ЛЮБЫМ предложениям. Как то ведь это реализуется на php

Спасибо за внимание!!!

 

[Breeze]

Не желательно привязывать данные к какому либо одному модеру, даже временно.

Пока модер редактирует привязка нужна ибо надо знать кто редактирует, когда начал и т.д., нажал "сохранить" -- записал в лог кто отредактировал, отвязал запись от модера.
Если один нажал "редактировать" и не сохранив ушёл кофе пить на сутки, второй может нажать кнопку "теперь я модератор этой штуки", дальше по обычной схеме.

Вариантов масса на самом деле.
Главное писать лог кто, что и когда делает.

 

[fixxxer]

Выдавай модератору по одному заданию, записывай при этом timestamp когда выдано и какому модератору. Модератору давай N минут на принятие решения. Если за N минут оно не принято, задание возвращается в очередь.

 

[fixxxer]

Не желательно привязывать данные к какому либо одному модеру, даже временно.

Без этого тебе придется реализовать совместную работу, как в google docs, и алгоритм разрешения конфликтов. Это очень сложная тема

 

[DarkLight]

Спасибо за ответы, значит всё же время нужно в этом функционале... Я надеялся, что может быть есть какие то простые решения, без участия времени))) В общем ещё раз спасибо, нужно верить своей интуиции и логике))) Тему можно закрывать))

 

[Вурдалак]

Не очень понятно что именно происходит при модерации. «Редактируют» ли они все одно и то же поле или разные?

Если уйти от CRUD-логики с одной большой формой, а оперировать небольшими и точными командами (ЗаблокироватьЮзера { userId }, ИзменитьИмяЮзеру { userId, newName }) и контролировать на уровне модели все возможные переходы (грубо говоря, не разрешать «повышать статус», если он уже «финальный»), делать методы идемпотентными (не изменять, если уже было изменено) и изменять модель транзакционно, то можно уйти от многих проблем с возможными конфликтами.

 

[DarkLight]

Не очень понятно что именно происходит при модерации. «Редактируют» ли они все одно и то же поле или разные?

Если уйти от CRUD-логики с одной большой формой, а оперировать небольшими и точными командами (ЗаблокироватьЮзера { userId }, ИзменитьИмяЮзеру { userId, newName }) и контролировать на уровне модели все возможные переходы (грубо говоря, не разрешать «повышать статус», если он уже «финальный») и изменять модель транзакционно, то можно уйти от многих проблем с возможными конфликтами.

Вопрос интересный, тут всё зависит от юзера чьи данные модерируются, допустим если юзер указал неправильные контакты для связи, то у модератора должна быть возможность редактирования контактов, допустим цифрой ошибся юзер в номере телефона или ещё чем. Если брать идеальные условия, то вся задача сводится только к проверке на правдивость данных предоставленных юзером и в зависимости от исхода, либо повышать статус до достижения финального, либо отклонять заявку оставляя статус прежним. Так то критически страшного для бизнес процесса ничего нет конечно, но такие вот моменты, как несколько одинаковых извещений 'Василий, поздравляем, Вы прошли проверку номер 1. С уважением, модератор такой то' и то что сразу несколько модеров могут начать долбить по контактам бедного юзера (но это уже другая тема, чтение, а не редактирование), основательно подпортят ситуацию в глазах юзера. Это так, примеры на вскидку.

 

[AnrDaemon]

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

 

[fixxxer]

но такие вот моменты, как несколько одинаковых извещений 'Василий, поздравляем, Вы прошли проверку номер 1

Пфф, и это все? Я-то думал.

У тебя есть заявка, кто первый ее выполнил - того и тапки. Если заявка уже выполнена - ничего не делаем.

 

[Вурдалак]

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

Это вопрос идемпотентности:

делать методы идемпотентными (не изменять, если уже было изменено)

 

[DarkLight]

Ок, всем огромное спасибо))) Дошло, что не всё так страшно и что не стоит переусложнять систему там, где не надо))))

 

[fixxxer]

@DarkLight, у тебя видимо проблема с тем, что заявка это просто как письмо произвольное, а модератор редактирует все, что захочет. Надо не так. Если заявка на повышение уровня, то у модератора две кнопочки - повысить уровень и послать к черту.

 

[AnrDaemon]

Нутипада. Сама заявка должна быть объектом бизнес-логики.

 

[DarkLight]

Я просто хотел учесть то, что юзер может неправильно что то вбить. Фио, емайл или что то другое с ошибкой. Что бы модер мог сам исправить. Хотя конечно можно добавить функционал что бы если 'послать к чёрту', модеру нужно было выбрать из преопределёного списка причину, например 'Несуществующий емайл' или что то в этом роде. Просто это лишний футболинг, если юзер неправильно или с опечатко ввёл имя, например Алескандер, что бы не просить юзера это исправить, а модер сам мог поправить

 

[AnrDaemon]

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

 

[Вурдалак]

Я просто хотел учесть то, что юзер может неправильно что то вбить. Фио, емайл или что то другое с ошибкой. Что бы модер мог сам исправить. Хотя конечно можно добавить функционал что бы если 'послать к чёрту', модеру нужно было выбрать из преопределёного списка причину, например 'Несуществующий емайл' или что то в этом роде. Просто это лишний футболинг, если юзер неправильно или с опечатко ввёл имя, например Алескандер, что бы не просить юзера это исправить, а модер сам мог поправить

Так а в чём проблема, корректировка имени и одобрение как-то конфликтуют? Ты же сам говоришь, что юзера можно не отфуболивать.

 

[DarkLight]

Ну так я отписал выше, что дошло - не всё так страшно и сложно, просчитался немного)))

Извините за беспокойство )))

Всем БОЛЬШОЕ СПАСИБО!