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