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