Внутренняя панель работает с реальными процессами и данными, поэтому её проектируют от действий сотрудников, ролей и границ доступа. Начинать только с генерации таблицы опасно: сотрудник может увидеть чужую запись, изменить статус без полномочий или выполнить административное действие не для той команды.
Кейс: очередь обращений поддержки
У команды есть четыре действия: просмотреть новые обращения, назначить ответственного, изменить состояние и закрыть обращение. Сначала задай роли:
| Роль | Рабочая задача | Доступный минимум |
|---|---|---|
| Агент поддержки | ответить на обращение | видеть назначенное и брать свободное из разрешённой очереди |
| Руководитель смены | распределять нагрузку | видеть обращения своей команды и менять назначение |
| Администратор | управлять правилами и сотрудниками | отдельные административные действия с повышенной проверкой |
Это пример для обсуждения, а не готовая матрица доступа для любой компании. В реальной системе могут быть юридические, организационные и конфиденциальные ограничения; их должен определить владелец процесса.
Для каждого действия запиши не только роль, но и контекст записи: агент может просматривать назначенное ему обращение; руководитель — записи своей команды; администратор — действие по обоснованной необходимости. Одного role=admin недостаточно, если данные ещё разделяются по филиалам или клиентским организациям.
Рабочий сценарий до экранов
Опиши путь одного обращения: новая запись приходит в очередь → агент открывает её → назначает себе или получает назначение → меняет статус на «в работе» → записывает результат ответа → завершает. Для каждого шага отметь, что видит пользователь, что сохраняется и кто может исправить ошибку.
Попроси ИИ сначала проверить схему процесса:
Создай прототип очереди обращений для трёх ролей: агент, руководитель смены и администратор. Сначала составь матрицу действий и области данных. Для каждого endpoint укажи server-side authorization check и ожидаемый отказ. Реальные данные не используй; создай явно синтетические записи. В UI не скрывай отказ так, будто операция прошла. До согласования прав код не генерируй.
После согласования сделай список и карточку на фиктивных данных. Подключение к реальному хранилищу добавляй только после проверки ролей и отрицательных случаев.
Проверки доступа выполняются на сервере
OWASP Authorization Cheat Sheet рекомендует применять принцип наименьших привилегий, запрещать по умолчанию и проверять разрешения на каждом запросе (OWASP Authorization). Эти рекомендации особенно важны для панели, где запрос можно отправить вручную, минуя кнопку. Скрытие «Удалить» в UI улучшает интерфейс, но не ограничивает серверный endpoint.
Если данные хранятся в PostgreSQL и применён Row Level Security, политики могут ограничивать доступ к строкам на уровне базы; Supabase описывает RLS и требует обдуманной настройки правил и прав (Supabase RLS). RLS не заменяет аутентификацию или проверку бизнес-операции. Проверь реальные роли приложения и убедись, что привилегированный ключ не оказался в клиентском коде.
Набор негативных проверок должен включать: без сессии запрос закрыт; агент не читает чужую команду; нельзя назначить себя администратором; агент не закрывает запись, если это действие не входит в его право; смена ID в URL не открывает чужую заявку. Тестируй каждый API-маршрут, а не только экран.
Удобная панель помогает не ошибиться
Покажи важный контекст записи до опасного действия: владелец, статус, команда, дата последнего изменения. Дай подтверждение для удаления/массового изменения и сообщай, когда запись уже изменил коллега. Для каждого перехода статуса определи, можно ли его отменить и где видна история. Если запись закрыта, кнопка «Ответить» должна следовать реальному процессу, а не оставаться активной только потому, что её сгенерировал шаблон.
Внутренние инструменты должны поддерживать рабочую последовательность, а не имитировать «красивый админ-дэшборд». Добавляй только те поля и фильтры, которые нужны сотруднику в данном сценарии. Для операций, влияющих на клиента, проверь кто выполнил изменение и каким был исходный статус. Не собирай лишнюю аналитику, если команде не определено, кто и зачем её использует.
Условия перехода от прототипа
Используй синтетические данные, пока не проверены роли, области видимости, история изменений, резервное восстановление и обработка ошибок. Для реальных данных нужен согласованный доступ и проверка путей хранения/логирования. Прототип на экране не доказывает, что команда может безопасно работать с production-данными; до такого шага требуется отдельный технический review и проверка на целевой инфраструктуре.
История изменений и защита от двух операторов
Для очереди поддержки полезна запись: кто назначил обращение, кто изменил статус и когда. Храни не только текущий статус, но и историю событий, если она нужна для разбирательства ошибок и передачи смены. Не записывай в журнал больше персонального содержимого, чем необходимо; для диагностики часто достаточно идентификатора, действия и результата проверки.
Добавь конкурентный сценарий: два агента открыли одну свободную заявку. Первый назначает её себе; второй почти одновременно пытается сделать то же. Сервер должен проверить текущее назначение в момент записи и вернуть конфликт проигравшему, а UI обновить строку и сообщить, кто уже работает с обращением. Кнопка, которая продолжает показывать «свободно», не должна выдавать ложное подтверждение.
Операционная проверка команды
Проверь маршрут с сотрудником в каждой тестовой роли: получена ли очередь; можно ли взять обращение; что происходит при повторном открытии; где видны новые сообщения; как передать задачу на другую смену; что видит сотрудник при потере сессии. Используй синтетические записи и отдельную среду. Убедись, что «ошибка сохранения» не оставляет заявку помеченной как закрытая только на экране.
Определи восстановление: как найти случайно закрытое обращение, кто может отменить ошибочное назначение и какие операции требуют вторичного подтверждения. Если массовая обработка нужна только руководителю, её следует отдельно выделить и тестировать выборку перед запуском. Запиши безопасный порядок действия и способ отменить изменение до того, как добавишь кнопку массового завершения.