При настройке системы безопасности в типовых и нетиповых конфигурациях 1С разработчики часто сталкиваются с задачей ограничить видимость данных, например, документов ЗаказКлиента по менеджеру или подразделению. В типовых решениях (таких как «1С:Управление торговлей 11», «1С:ERP» или «1С:Комплексная автоматизация») список ролей может насчитывать сотни элементов. Прописывать сложное условие RLS вручную в каждую роль по отдельности — неэффективно и чревато ошибками. Разберем по шагам, какими штатно встроенными инструментами платформы можно быстро растиражировать правило, а также выясним, почему прямое копирование условий в роли типовых конфигураций может создать проблемы.
В платформе «1С:Предприятие 8.3» предусмотрен встроенный визуальный механизм группового управления условиями RLS. Часто разработчики ищут эту возможность внутри свойств конкретной роли, однако точка входа находится на уровень выше. Разберем этот процесс подробно:
ЗаказКлиента), для которого уже задано нужное условие ограничения.Этот способ позволяет за секунды растиражировать текст условия или вызов шаблона RLS по десяткам и сотням ролей без необходимости ручного редактирования каждой из них.
Проанализируем важный аспект платформенного механизма контроля доступа, из-за которого возникает необходимость модифицировать сразу все роли. В 1С действует фундаментальный принцип: права пользователей суммируются по логическому правилу «ИЛИ».
Если у пользователя назначено несколько ролей, дающих право на чтение одного и того же объекта, то:
По этой причине нельзя просто создать одну новую вспомогательную роль с жестким RLS и добавить ее в существующий профиль менеджера. Если у пользователя останется хотя бы одна типовая роль, дающая право чтения заказа клиента без RLS, ограничение попросту не сработает. Именно поэтому разработчикам приходится либо модифицировать все роли с правом чтения, либо пересматривать профили доступа.
Если конфигурация выгружена в файлы или находится в системе контроля версий (Git), можно воспользоваться автоматической обработкой XML-файлов описания прав. Рассмотрим логику этого подхода:
<name>Read</name>
<value>true</value>
<restrictionByCondition>
<condition>ТекущаяТаблица ГДЕ ТекущаяТаблица.Менеджер = &ТекущийПользователь</condition>
</restrictionByCondition>
Прежде чем внедрять ручные RLS во все 150 ролей конфигурации «Управление торговлей 11», «ERP» или «КА», проанализируем последствия такого решения для дальнейшей эксплуатации системы.
1. Трудоемкость обновлений: Роли в типовых конфигурациях находятся на поддержке. Добавление нетиповых условий RLS в десятки ролей снимает их с полной поддержки поставщика. При каждом последующем обновлении конфигурации программисту придется вручную отслеживать изменения прав и повторно переносить свои условия.
2. Конфликт с ключами доступа БСП: В современных редакциях «Библиотеки стандартных подсистем» (БСП) используется механизм производительного RLS, базирующийся на служебных регистрах сведений ключей доступа. Если встроить в роли прямое платформенное условие в обход шаблонов БСП, это приведет к рассогласованию прав, ошибкам фонового пересчета прав и некорректной работе отчетов.
3. Производительность СУБД: Прямые платформенные условия RLS к таблицам документов модифицируют каждый запрос к базе данных, принудительно вставляя подзапросы. Это вызывает резкое замедление работы динамических списков, проведения документов и провоцирует взаимные блокировки данных при одновременной работе пользователей.
Выясним, какие штатные архитектурные альтернативы существуют в УТ 11 для разделения видимости документов между менеджерами:
УправлениеДоступомПереопределяемый). В этом случае в ролях используются стандартные шаблоны доступа (например, #ПоЗначениям), расчет прав оптимизируется через регистры ключей доступа, а логику видимости (включая замещение менеджеров на время отпусков) можно гибко настраивать в пользовательском интерфейсе.Менеджер. Такое решение можно реализовать через расширение конфигурации, оно не утяжеляет запросы к базе данных и не снижает скорость проведения документов.