Портал на Payload

Личный кабинет или портал заявок на Payload CMS 3 собирается из штатных механизмов: коллекция пользователей с авторизацией, правила доступа на коллекциях и полях, хуки для статусов и писем, поля загрузки файлов. Партнёр видит только свои заявки, менеджер все, заявку без обязательных фото нельзя отправить, переписка идёт внутри заявки, а письма уходят с вашей почты. Всё это описано кодом в одном приложении Next.js, без второго бэкенда и сторонних плагинов. Так устроен портал гарантийных заявок ДС Энерджи, который мы запустили в сентябре 2026 года, ниже по частям, как это собирается.

Кабинет в админке или отдельный фронт

Первое решение: где будут работать пользователи.

Для портала заявок почти всегда хватает админки. Пользователи портала заходят каждый день и работают с формами, им важны скорость и понятные поля. Сэкономленное время уходит на логику.

Роли и доступ

Пользователи хранятся в коллекции с auth: true, роль это обычное поле select. Права описываются функциями доступа на каждую операцию коллекции: create, read, update, delete и admin (пускать ли в админку). Функция может вернуть true, false или условие выборки, и тогда пользователь видит только подходящие записи. Отдельно работают права на уровне полей: create, read, update для каждого поля.

Пример для портала гарантийных заявок:

Главное свойство: правила живут в схеме коллекции, а не во фронте. Payload применяет их одинаково в админке, REST, GraphQL и Local API. Если поле скрыто от роли, оно не придёт и в ответе API, спрятать его только в интерфейсе не получится. Файлы из коллекции загрузок отдаются через Payload с проверкой тех же прав, поэтому фото чужой заявки по прямой ссылке не откроется.

Статусы и переходы

Статус заявки это поле select, а порядок переходов проверяется в хуке beforeChange коллекции. Хук получает новое значение в data и прежнее в originalDoc, знает пользователя из req и отклоняет запрещённый переход с понятной ошибкой.

В хуке afterChange сравниваем doc.status с previousDoc.status и при смене статуса отправляем письмо нужной стороне. Там же пишем запись в журнал: кто, когда, из какого статуса в какой. Если нужна полная история всех правок, включаем у коллекции версии, и в админке появится вкладка с каждым сохранённым состоянием заявки.

Обязательные файлы

Фото и документы хранятся в коллекции с upload: true, в заявке это поля типа upload со связью на неё. Обязательность задаётся на уровне схемы: required: true у поля или своя функция validate, если правило сложнее, например "не меньше двух фото шильдика" или "акт нужен только для платного ремонта". Опция mimeTypes ограничивает типы файлов (image/*, application/pdf), imageSizes делает уменьшенные копии для быстрого просмотра.

На портале ДС Энерджи к каждой заявке нужны гарантийный талон, акт и фото шильдика котла. Без них заявку нельзя отправить, и проверка работает на сервере, поэтому никакой фронт её не обойдёт. Большие объёмы файлов лучше хранить в S3-совместимом хранилище российского провайдера через официальный адаптер @payloadcms/storage-s3.

Переписка по заявке

Комментарий одним полем, которое каждый перезаписывает, быстро превращается в путаницу. Мы делаем переписку отдельной коллекцией сообщений: у каждого сообщения связь с заявкой, автор, текст, вложения и время. В самой заявке поле join показывает ленту сообщений прямо в карточке, как чат.

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

Вход, пароли и письма

Коллекция пользователей с auth даёт из коробки вход по email и паролю, выход, сброс пароля, получение текущего пользователя и обновление токена. В браузере Payload держит сессию в HTTP-only cookie, недоступной скриптам на странице, а мобильному приложению или интеграции отдаёт JWT. Штатные опции, которые мы настраиваем почти всегда:

• tokenExpiration, сколько живёт сессия;
• maxLoginAttempts и lockTime, блокировка после серии неудачных попыток;
• verify, подтверждение email для самостоятельной регистрации;
• forgotPassword, свой шаблон письма сброса на русском;
• useAPIKey, ключи для внешних систем.

Письма отправляются через адаптер @payloadcms/email-nodemailer по SMTP с ящика на вашем домене. Отдельно настраиваем SPF, DKIM и DMARC, иначе корпоративные почты партнёров будут складывать письма в спам. На переезде ДС Энерджи именно доставка писем была одной из причин уйти с Firebase: письма сброса пароля от Google доходили не до всех.

Телефон и камера

Админка Payload адаптивная, списки и формы нормально работают на экране телефона. Поле загрузки файла на телефоне предлагает выбрать снимок из галереи или сразу снять камерой. Писать для этого отдельное приложение не нужно. Для сервисного инженера, который оформляет заявку у котла, это оказалось самой полезной частью портала.

Как мы делали портал ДС Энерджи

ДС Энерджи производит котельное оборудование. Сервисные центры заводят гарантийные заявки с фото, производитель проверяет их и оплачивает работы. Портал раньше работал на Firebase, в 2026 году мы перевезли его на Payload, подробно про сам переезд на странице переезд с Firebase.

Сверх переноса данных портал получил:

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

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

Что нужно от вас

• Список ролей и что каждая должна видеть и делать. Таблицы, как выше, достаточно.
• Статусы заявки и кто их переключает.
• Какие документы и фото обязательны и в каких случаях.
• Какие письма и кому уходят при каких событиях.
• Образцы текущих форм, таблиц Excel или доступ к старой системе, если она есть.
• Почтовый ящик на вашем домене и доступ к DNS для настройки SPF и DKIM.

Этапы

1. Разбираем процесс и фиксируем роли, статусы, поля и письма в одной таблице.
2. Схема коллекций и права доступа, первая версия в админке на тестовом сервере.
3. Вы с парой реальных пользователей работаете на тесте, мы правим поля и переходы.
4. Письма, перенос данных из старой системы, если он нужен.
5. Запуск на вашем сервере и две недели наблюдения за логами.

Сроки зависят от числа ролей и статусов, объёма переноса и интеграций, поэтому вилку называем только после разбора процесса. Для ориентира: на ДС Энерджи перенос данных, пользователей и файлов вместе с новой логикой занял около полутора месяцев, потом клиент тестировал портал параллельно со старым.

Сколько стоит

Считаем по часам после просмотра задачи. На цену влияют число ролей и статусов, сложность правил проверки, объём переноса, количество писем и внешних интеграций, нужен ли отдельный фронт вместо админки. Хостинг после запуска это обычный VPS в России с Docker и PostgreSQL, оплата хостеру в рублях. Про выбор базы подробнее в статье Postgres или MongoDB для Payload.

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