Роли и разграничение доступа

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

Почему роли нельзя «добавить потом»

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

Администратор видит настройки и пользователей. Менеджер видит свои записи или записи отдела. Клиент видит только свои заказы. Это разные стартовые экраны с разной навигацией — не одна страница со спрятанными кнопками.

Что фиксирую в смете

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

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

Связь с кабинетом и CRM

Роли почти всегда идут вместе с кабинетом или CRM. Отдельной «надстройкой за вечер» они не собираются. Я проектирую их как часть архитектуры, а не как плагин. Оплата 50/50, объём — в смете.