Роль «Менеджер» ещё не объясняет, какие данные сотрудник может видеть и менять. Разбираем, как до разработки составить матрицу доступа, описать границы между отделами и организациями, а затем проверить разрешённые и запрещённые действия.
В техническом задании указаны три роли: сотрудник, руководитель и администратор. На демонстрации выясняется, что руководитель должен видеть только свой филиал, сотрудник может менять заявку до согласования, а администратору не нужны финансовые отчёты. Эти ограничения влияют на архитектуру приложения, поэтому их стоит описать до разработки экранов.
Начните с объектов и действий
Матрица доступа связывает пользователя, объект и допустимую операцию. Для заявки это могут быть просмотр, создание, редактирование, согласование и выгрузка. Возможность открыть карточку не означает право менять её или скачивать приложенные документы. Каждое значимое действие нужно рассмотреть отдельно.
Запишите, какими данными управляет приложение: клиентами, договорами, задачами, платежами. Затем обсудите операции с владельцами процессов. Формулировка «Полный доступ к заявкам» слишком широка: за ней могут скрываться удаление истории, смена ответственного и массовый экспорт, которые требуются разным сотрудникам.
Добавьте границы видимости
Одинаковая роль не всегда даёт доступ к одинаковому набору записей. Менеджер работает со своими клиентами, начальник отдела - с клиентами подразделения, партнёр - с данными своей организации. В матрице указывают не только «можно смотреть», но и область, в которой действует разрешение.
Учитывайте состояние документа
Черновик заявки разрешено редактировать автору, после отправки его может потребоваться заблокировать, а согласованный документ менять через отдельную процедуру. Для каждого перехода определите инициатора и результат. Это избавит команду от противоречивого правила «редактировать можно, но не всегда».
Рассмотрите и совместную работу. Если сотрудник временно замещает коллегу, доступу нужны срок действия и основание. Не стоит создавать новую постоянную роль под каждое исключение: сначала отделите устойчивые обязанности от временного поручения, иначе набор разрешений станет трудно объяснить и проверить.
Разделите настройку системы и работу с данными
Техническому администратору может требоваться управление пользователями, но не согласование коммерческих условий. Руководителю нужен отчёт отдела, однако это не обязательно даёт право удалять чужие учётные записи. Названия должностей сами по себе не определяют полномочия в приложении.
Для каждой операции зафиксируйте ожидаемое решение. Если разрешение не задано, безопаснее считать действие недоступным. Скрытая кнопка помогает интерфейсу оставаться понятным, но не заменяет проверку прав при обработке запроса. Ограничения должны действовать и при обращении к данным без обычного перехода по экрану.
Опишите спорные ситуации заранее
Что происходит с задачами после перевода человека в другой отдел? Сохраняет ли бывший ответственный доступ к переписке? Кто передаёт документы при увольнении? Ответы лучше согласовать на примерах записей, а не оставлять разработчику как «очевидное поведение». Для важных изменений полезна история автора, времени и результата операции.
Превратите матрицу в критерии приёмки
Подготовьте тестовых пользователей из двух отделов или компаний и несколько документов в разных состояниях. Для каждой роли проверьте разрешённую операцию и похожую запрещённую: например, просмотр своей заявки и попытку открыть чужую. Отдельного внимания требуют файлы, поиск и выгрузки, где ограничение видимости легко пропустить.
У матрицы должен быть владелец со стороны бизнеса. Изменение процесса сначала отражают в правилах, затем в реализации и проверках. Иначе документ быстро устареет, а фактические полномочия будут зависеть от разовых просьб сотрудников и давних настроек.
Kommutator.net проектирует приложения вокруг рабочих процессов и интеграций. Если в системе несколько ролей и областей данных, матрицу доступа стоит включить в подготовку требований к веб-приложению. Согласованные примеры помогут оценить объём разработки и сделать приёмку понятной заказчику.