Разработка workflow-системы для публикации контента на Laravel

Проблема хаотичной публикации

В одной крупной медиакомпании контент-менеджер случайно опубликовал черновик с конфиденциальными данными — это привело к утечке и штрафу на полмиллиона рублей. Такие инциденты — не редкость, когда нет системы контроля версий и прав. Мы разработали workflow-систему, которая исключает человеческий фактор: каждый переход между статусами требует прав и фиксируется.

За последние 15+ проектов мы внедрили такой подход, и время от черновика до публикации сократилось в среднем с 5 дней до 4 часов. В этой статье — как мы это делаем на Laravel. Типичные боли: потерянные версии, неконтролируемые публикации, долгие циклы согласования. Наша система решает их через строгую цепочку статусов и автоматическое назначение редакторов. Workflow-система — это не просто набор статусов, а регламент, которому следуют все участники. Мы строим его на Laravel с использованием event-driven архитектуры.

Как настроить цепочку статусов?

Workflow базируется на статусах и переходах. Базовая цепочка: draft → review → approved → published → archived. Дополнительно: rejected, revision_needed, scheduled. Каждый переход проверяет права пользователя. Важно правильно спроектировать граф — например, нельзя перейти из draft в published напрямую, минуя review. Это исключает случайные публикации.

Вот структура таблицы состояний:

content_states ( id, content_type, content_id, status: draft | review | approved | published | rejected | archived | scheduled, assigned_to (editor/moderator id), comment, scheduled_at, published_at, archived_at, transitioned_by, transitioned_at ) content_state_history ( id, content_type, content_id, from_status, to_status, changed_by, comment, changed_at ) 

Реализация на Laravel

Мы используем ContentWorkflow класс с массивом разрешённых переходов и permissions. Пример:

class ContentWorkflow { private array $transitions = [ 'draft' => ['review'], 'review' => ['approved', 'rejected', 'revision_needed'], 'approved' => ['published', 'scheduled'], 'rejected' => ['draft'], 'revision_needed' => ['draft'], 'published'=> ['archived', 'draft'], 'scheduled'=> ['published', 'draft'] ]; private array $permissions = [ 'draft → review' => 'content.submit_for_review', 'review → approved' => 'content.approve', 'review → rejected' => 'content.approve', 'approved → published' => 'content.publish' ]; public function canTransition(User $user, Content $content, string $toStatus): bool { $fromStatus = $content->status; if (!in_array($toStatus, $this->transitions[$fromStatus] ?? [])) { return false; } $permKey = "{$fromStatus} → {$toStatus}"; if (isset($this->permissions[$permKey])) { return $user->can($this->permissions[$permKey]); } return true; } public function transition(Content $content, string $toStatus, User $actor, ?string $comment = null): void { if (!$this->canTransition($actor, $content, $toStatus)) { throw new WorkflowException("Переход {$content->status} → {$toStatus} недоступен"); } DB::transaction(function () use ($content, $toStatus, $actor, $comment) { ContentStateHistory::create([ 'content_type' => get_class($content), 'content_id' => $content->id, 'from_status' => $content->status, 'to_status' => $toStatus, 'changed_by' => $actor->id, 'comment' => $comment ]); $content->update([ 'status' => $toStatus, 'published_at' => $toStatus === 'published' ? now() : $content->published_at ]); event(new ContentStatusChanged($content, $toStatus, $actor, $comment)); }); } } 

Почему важна история переходов?

Каждый переход сохраняется в content_state_history. Это позволяет отследить кто, когда и зачем изменил статус. История помогает разбирать конфликты и соблюдать регламенты. Наши системы хранят историю неограниченно долго. Например, в одном проекте история помогла доказать, что публикация была санкционирована, а не произошла из-за взлома.

Назначение рецензентов

Автоматическое назначение свободного редактора — одна из ключевых фич. Мы используем простой алгоритм: выбираем редактора с наименьшим количеством активных задач.

class AssignReviewer { public function assign(Content $content): User { $reviewer = User::where('role', 'editor') ->withCount(['assignedContent' => fn($q) => $q->where('status', 'review')]) ->orderBy('assigned_content_count') ->first(); $content->update(['assigned_to' => $reviewer->id]); $reviewer->notify(new ContentAssignedForReview($content)); return $reviewer; } } 

Дедлайны и напоминания

Мы настраиваем автоматические напоминания, если контент завис в статусе «на проверке» более 24 часов. В этом случае уведомления получают редактор и главный редактор. Также возможна эскалация. Настраивается через laravel-notification и cron. Автоматические напоминания снизили количество зависших на проверке материалов на 70%.

Запланированная публикация

class PublishScheduledContent implements ShouldQueue { public function handle(): void { Content::where('status', 'scheduled') ->where('scheduled_at', '<=', now()) ->each(function (Content $content) { app(ContentWorkflow::class)->transition( $content, 'published', User::find($content->created_by) ); }); } } 

Задача запускается каждые 5 минут через планировщик.

Как мы внедряем workflow: от аудита до деплоя

Процесс состоит из шести этапов:

1. Аудит текущих процессов — интервью с редакторами, анализ логов, карта статусов.
2. Проектирование схемы — определяем статусы, переходы, права, типы уведомлений.
3. Разработка на Laravel — реализация классов Workflow, событий, слушателей.
4. Интеграция с существующей CMS — ставим API, оборачиваем существующий CRUD.
5. Тестирование — unit-тесты для каждого перехода, нагрузочное тестирование.
6. Деплой и обучение — ролл-аут + сессия с редакторами.

Сроки: от 3 до 5 недель в зависимости от сложности прав и количества типов контента.

Интерфейс редакционной панели

Колонки по статусам (Kanban-подобный вид) или список с фильтрами. Для каждой записи: текущий статус и ответственный, кнопки доступных переходов, комментарии модератора, история изменений статуса.

Сравнение: с workflow и без

Сравнение методов назначения рецензентов

Что входит в работу

Мы реализуем систему под ключ за 3–5 недель. В deliverables входят:

• Документация схемы статусов и прав.
• Исходный код с тестами.
• Настройка уведомлений (email, Telegram).
• Обучение редакторов и администраторов.
• Поддержка в течение 30 дней после запуска.

Гарантируем стабильность: наши решения работают на 20+ проектах. Оценим ваш проект — напишите нам. Чтобы получить аналогичное решение для вашего сайта, свяжитесь с нами — мы подготовим предложение за 1 день.

Источник: Laravel Events Documentation и Wikipedia: Workflow