Права доступа в личном кабинете бизнеса: роли сотрудников, клиентов и журнал действий

В личном кабинете заказчик может следить за своей заявкой, менеджер — вести обращения, а руководитель — распределять работу. Одинаковый экран для всех не означает одинаковые полномочия. До разработки стоит описать, кому нужны просмотр, создание, изменение, назначение ответственного, выгрузка и удаление записей.

Удобная основа для обсуждения — матрица доступа: роль, объект, действие и условие. Например, клиент читает только заявки своей организации; менеджер меняет назначенные ему обращения; руководитель перераспределяет заявки своего подразделения. Это пример проектирования, а конкретные правила нужно согласовать с владельцем процесса.

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

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

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

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

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

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

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

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

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

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

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

В услугу разработки веб-приложений AI-студии входят проектирование ролей, данных и экранов, разработка согласованных функций и проверка сценариев. Подробные правила доступа, авторизацию, журнал и интеграции нужно включить в согласованный состав работ. Объём, этапы и оценку обсуждают после описания процесса; готовая матрица доступа делает такое обсуждение предметным.