Разработка личного кабинета: как спроектировать роли и доступы

Начните с матрицы «кто что может», а не с экранов

Возьмите таблицу. В строках — действия, которые вообще существуют в системе. В столбцах — типы людей. В клетках — «да», «нет» или «только своё». Это займёт час и заменит половину техзадания.

Формулируйте действия глаголами и максимально узко. Не «работа с заказами», а отдельно: видеть список заказов, видеть чужой заказ, менять статус, отменять, видеть себестоимость, выгружать в Excel. Разница между «видеть заказы» и «видеть все заказы» — это часто разница между рабочим кабинетом и утечкой данных.

Отдельно пометьте клетки со словом «только своё». Именно они дают больше всего ошибок в разработке, потому что требуют проверки на каждом запросе, а не одной галочки в настройках.

• Видеть данные — свои, своего отдела, все
• Создавать и редактировать — свои записи или любые
• Удалять — почти всегда стоит заменить на «архивировать»
• Видеть деньги: закупочные цены, маржа, зарплаты
• Выгружать данные списком — это отдельное право, не то же самое, что «смотреть»
• Управлять людьми: приглашать, менять роль, отзывать доступ

Роль — это не должность и не конкретный человек

Частая ошибка: роли называют именами сотрудников или точными должностями из штатного расписания. Через полгода штат меняется, и в системе живут «Роль для Ирины» и «Менеджер-2». Роль описывает набор прав, а не человека.

Для малого и среднего бизнеса в 90% случаев хватает трёх-четырёх ролей: владелец аккаунта, администратор, сотрудник, клиент. Владелец — единственный, кто платит, удаляет аккаунт и передаёт права. Администратор делает всё по работе, но не может выкинуть владельца. Сотрудник видит только свой участок.

Если при обсуждении вам кажется, что нужно семь ролей, скорее всего вам нужны три роли и пара переключателей внутри них — например, «видит закупочные цены» отдельной галочкой. Так дешевле в разработке и понятнее в поддержке.

И заранее ответьте на скучный вопрос: что происходит, когда человек уходит. Удалять его нельзя — вместе с ним пропадёт история его заказов и комментариев. Правильный ответ — деактивировать: вход закрыт, данные остались.

Где доступы ломаются на практике

Самая распространённая дыра — проверка прав только в интерфейсе. Кнопку «Удалить» спрятали, а сам запрос на удаление сервер по-прежнему выполняет от кого угодно. Права должны проверяться на сервере, при каждом запросе, и это не опция, а норма.

Вторая — доступ по прямой ссылке. Проверить можно руками, без разработчика: зайдите под сотрудником, откройте свою запись, найдите в адресе номер (например, /orders/1043), поменяйте его на соседний и обновите страницу. Если открылась чужая запись — доступы сделаны неправильно. Тот же тест повторите со ссылками на файлы: договор или скан паспорта не должны открываться в режиме инкогнито.

Третья — экспорт и уведомления. Сотрудник не видит чужие сделки в списке, но выгружает CSV со всей базой или получает письмо с суммами по всей компании. Эти два канала почти всегда забывают включить в матрицу прав.

Что должно быть в кабинете помимо самих прав

Кабинет живёт годами, и половина работы с ним — это администрирование людей, а не бизнес-задачи. Если этих вещей нет, вы будете дёргать подрядчика по каждому новому сотруднику и платить за работу, которую могли бы делать сами.

Минимальный набор, который стоит внести в техзадание отдельными пунктами:

• Приглашение по email или ссылке, а не «разработчик создаст пользователя вручную»
• Смена роли и отзыв доступа в один клик, без обращения в поддержку
• Журнал действий: кто и когда изменил статус, цену, удалил запись
• Самостоятельное восстановление пароля
• Двухфакторная авторизация хотя бы для владельца и администраторов
• Понятный экран «Доступ запрещён» вместо белой страницы или ошибки

Когда личный кабинет не нужен

Если у вас 10–15 клиентов и вы знаете каждого по имени, кабинет им не нужен. Им нужна ссылка на документ, письмо со статусом или Telegram-бот, который отвечает на два вопроса. Кабинет для десяти человек — это чаще всего покупка чувства «у нас как у взрослых», а не решение задачи.

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

Честный подрядчик на этом этапе должен спросить, сколько у вас пользователей и что именно они делают ежедневно. Если сразу предлагают кабинет с шестью ролями, не задав ни одного вопроса про процессы — это продажа объёма.

Что делает разработку личного кабинета дороже и как проверить смету

Стоимость растёт не от количества экранов, а от количества комбинаций «роль × действие». Каждая клетка «только своё» — это дополнительная логика и дополнительный тест. Поэтому две лишние роли могут стоить дороже, чем целый новый раздел.

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

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

У нас в EFIMOV DEV на сайте опубликованы вилки «от» по каждому направлению — сайты, интернет-магазины, веб-сервисы с кабинетами, Telegram-боты, поддержка. Точную смету считаем после брифа, потому что до разговора про роли и права любая цифра будет угадыванием, и обсуждать задачу вы будете напрямую с тем, кто ведёт проект.