При разработке в типовых решениях на базе БСП (Библиотеки стандартных подсистем), таких как УТ 11.4, ERP 2.4/2.5 или КА 2.4, разработчики часто сталкиваются с необходимостью внедрения разграничения доступа на уровне записей (RLS) для новых объектов. В современных версиях этих конфигураций используется так называемый производительный режим RLS. Рассмотрим подробно, как правильно интегрировать новый документ в эту систему, какие существуют ограничения при использовании расширений и как их обойти.
Для начала проанализируем, в чем заключается принципиальная разница. В старом механизме RLS условия проверки прав добавлялись платформой динамически к каждому запросу. Это сильно нагружало базу данных при больших объемах данных. Новый производительный механизм работает иначе: система заранее рассчитывает права доступа для каждого объекта и сохраняет их в специальные регистры сведений (например, РегистрСведений.КлючиДоступаКОбъектам). Шаблон RLS в ролях теперь не выполняет сложные соединения таблиц, а просто проверяет наличие готового ключа в этом регистре.
Если вы добавили новый документ и прописали в роли шаблон #ДляОбъекта(""), но не выполнили сопутствующие настройки в коде и метаданных, система доступа «не увидит» ваш объект. В результате пользователь получит пустой список документов, либо система выдаст ошибку: «Невозможно обновить ключ доступа объекта... так как этот тип не указан в определяемом типе ВладелецЗначенийКлючейДоступа».
Для того чтобы подсистема управления доступом начала отслеживать ваш новый документ, его необходимо включить в состав определенных типов метаданных. Рассмотрим ситуацию, когда документ создан в расширении или в самой конфигурации.
Выясним главную проблему расширений: если ваша конфигурация находится на режиме совместимости ниже 8.3.20 (что типично для многих версий УТ 11.4), вы не сможете расширить состав определяемых типов через механизм расширений. При попытке захватить определяемый тип в расширение и изменить его состав, вы можете столкнуться с тем, что система требует перенести в расширение все объекты, входящие в этот тип, что делает расширение огромным и бесполезным.
Решение: В данной ситуации наиболее правильным и «чистым» вариантом будет включение возможности изменения основной конфигурации (с сохранением поддержки) и добавление вашего документа в следующие определяемые типы напрямую:
ВладелецЗначенийКлючейДоступа — добавьте ссылку на ваш документ (ДокументСсылка.ИмяВашегоДокумента).ВладелецЗначенийКлючейДоступаДокумент — добавьте объект вашего документа (ДокументОбъект.ИмяВашегоДокумента).Это минимальное вмешательство в ядро системы, которое позволит БСП корректно обрабатывать ключи доступа для вашего объекта.
Просто добавить тип недостаточно. Нужно «объяснить» системе, по каким полям будет строиться ограничение (например, по Организации, Складу или Подразделению). Разберем, как это сделать. В модуле менеджера вашего документа необходимо создать экспортную процедуру ПриЗаполненииПараметровОграниченияДоступа.
Рассмотрим пример кода для ограничения доступа по полю Организация:
Процедура ПриЗаполненииПараметровОграниченияДоступа(Ограничения) Экспорт
Ограничения.Текст =
"РазрешитьЧтениеИзменение
|ГДЕ
|ЗначениеРазрешено(Организация)";
КонецПроцедуры
Если вы хотите использовать стандартный шаблон БСП для производительного режима, код может выглядеть так:
Процедура ПриЗаполненииПараметровОграниченияДоступа(Ограничения) Экспорт
Ограничения.Текст = "#ДляОбъекта(""Организация"")";
КонецПроцедуры
Важный нюанс: Если документ находится в расширении, создайте этот метод в модуле менеджера документа внутри расширения. Система БСП через механизмы рефлексии найдет этот метод и вызовет его при расчете прав.
Теперь перейдем к настройке прав в самих ролях. В роли на право «Чтение» (или «Изменение») для вашего документа необходимо добавить ограничение доступа. Используем современный шаблон #ДляОбъекта.
Проанализируем синтаксис шаблона:
#ДляОбъекта("Организация")
Здесь "Организация" — это имя реквизита вашего документа, по которому будет фильтроваться доступ. Если в конфигурации включен производительный режим RLS, этот шаблон будет обращаться к заранее рассчитанным ключам доступа.
Важно: Не пытайтесь смешивать старые шаблоны (например, #ПоЗначению) и новый производительный режим (включенный в константах). Это приведет к тому, что запросы будут работать некорректно или крайне медленно.
Чтобы БСП узнала о существовании новых настроек прав, часто требуется обновить вспомогательные данные. Рассмотрим, как это сделать программно или с помощью инструментов администратора.
УправлениеДоступом.ОбновитьКлючиДоступа(Тип("ДокументСсылка.ИмяВашегоДокумента"));
Рассмотрим ситуацию, когда у вас есть возможность использовать современную платформу и режим совместимости установлен в 8.3.20 и выше. В этом случае жизнь разработчика упрощается:
Вам достаточно создать расширение, добавить в него нужные определяемые типы и просто дополнить их своими объектами без необходимости захвата всей конфигурации. Платформа версии 8.3.20 умеет объединять составы типов из основной конфигурации и расширений. Однако помните, что для УТ 11.4 это актуально только в самых свежих релизах, так как типовые решения долго сохраняют старые режимы совместимости для поддержки работы на старых серверах.
Проанализировав ситуацию, можно сделать вывод: при работе с RLS в УТ 11.4 наиболее стабильным решением остается частичное изменение основной конфигурации в части определяемых типов. Посмотрим на алгоритм еще раз кратко:
ПриЗаполненииПараметровОграниченияДоступа.#ДляОбъекта.Такой подход гарантирует, что ваш новый документ будет бесшовно интегрирован в общую систему безопасности предприятия, а производительность базы данных не упадет при росте количества записей.