В современных конфигурациях 1С, построенных на базе Библиотеки стандартных подсистем (БСП), часто возникает задача тонкой настройки прав доступа. Одной из типичных задач является ограничение видимости банковских счетов: например, необходимо разрешить пользователю видеть счета юридических лиц (контрагентов), но запретить доступ к счетам физических лиц. Рассмотрим, как правильно реализовать такое ограничение на уровне записей (RLS), разберем синтаксические особенности шаблонов БСП и выясним, почему внесенные изменения могут не сразу вступать в силу.
Представим ситуацию: в нашей информационной базе справочник БанковскиеСчетаКонтрагентов (или аналогичный) имеет поле Владелец, которое может ссылаться как на контрагента, так и на физическое лицо. Нам нужно создать роль, при которой пользователь сможет просматривать записи только в том случае, если владельцем является организация или контрагент. Если владельцем выступает физическое лицо, запись должна быть скрыта.
Для решения этой задачи в 1С используется механизм RLS (Record Level Security). В типовых решениях этот механизм работает через специальные шаблоны БСП, такие как #ПоЗначениям или #ПоЗначениямРасширенный. Эти шаблоны позволяют не писать сложные SQL-подобные запросы вручную, а использовать готовую структуру параметров.
Одной из самых частых ошибок при настройке RLS является неверное количество запятых в конструкции шаблона. Проанализируем структуру стандартного шаблона #ПоЗначениям, который используется для простых условий. Как правило, шаблон ожидает фиксированное количество параметров. Если вы передадите меньше или больше, система выдаст ошибку "Ожидается параметр".
Рассмотрим структуру вызова шаблона:
"Условие".Посмотрим на пример корректного написания условия, если нам нужно оставить доступ только для контрагентов:
#Если &ОграничениеДоступаНаУровнеЗаписейУниверсально #Тогда
#ДляОбъекта("")
#Иначе
#ПоЗначениям("Справочник.БанковскиеСчетаКонтрагентов", "Чтение", "", "Условие", "Т.Владелец ССЫЛКА Справочник.Контрагенты", "","","","","","","","","","","","","","","","","","","","","","","","","","" )
#КонецЕсли
Обратите внимание: в примере выше используется большое количество пустых кавычек. Это необходимо, так как шаблон рассчитан на проверку множества видов доступа одновременно, и даже если вы используете только один (условие), остальные позиции должны быть явно обозначены запятыми.
Для проверки типа владельца в языке запросов RLS лучше всего использовать оператор ССЫЛКА. Проанализируем, почему это предпочтительнее, чем использование функции ТипЗначения:
ССЫЛКА работает быстрее на уровне базы данных (SQL), так как напрямую проверяет принадлежность идентификатора к таблице метаданных.ТипЗначения может приводить к неявным соединениям с таблицами типов, что замедляет выборку данных, особенно в больших справочниках.Пример оптимального условия для нашей задачи:
Т.Владелец ССЫЛКА Справочник.Контрагенты
Выясним важный нюанс: современные версии БСП поддерживают два режима работы ограничений доступа. Если ваши правки в роли не дают никакого результата, скорее всего, в базе включен Производительный режим.
Стандартный режим: Логика RLS берется напрямую из настроек ролей в конфигураторе. Каждое обращение к базе данных дополняется условием из роли.
Производительный режим: Ограничения хранятся в специальных служебных таблицах (регистрах). В этом случае правки в конфигураторе (в окне роли) игнорируются системой. Логику необходимо прописывать в Модуле менеджера соответствующего объекта. Рассмотрим, как это выглядит на практике.
В модуле менеджера справочника БанковскиеСчетаКонтрагентов найдем процедуру ПриЗаполненииОграниченияДоступа и добавим туда программный код:
Процедура ПриЗаполненииОграниченияДоступа(Ограничение) Экспорт
Ограничение.Текст =
"РазрешитьЧтениеГде
|Владелец ССЫЛКА Справочник.Контрагенты";
КонецПроцедуры
После изменения кода в модуле менеджера обязательно нужно выполнить обновление данных доступа. Для этого можно запустить программу с параметром ЗапуститьОбновлениеИнформационнойБазы или использовать обработку "Обновление вспомогательных данных" из состава БСП. Для выборочного обновления данных доступа без полного перезапуска процедур подойдёт инструмент для точечного пересчета прав доступа пользователей.
Проанализируем ситуацию, когда условие написано верно, но пользователь все равно видит счета физических лиц. В системе 1С права работают по принципу объединения (кумулятивности). Это означает, что если у пользователя есть хотя бы одна роль, которая дает неограниченное право на чтение данного справочника, то любые ограничения в других ролях будут проигнорированы. Для анализа пересечений ролей и ограничений RLS можно использовать обработку для комплексного анализа прав и ограничений доступа.
Выполним следующие шаги для диагностики:
ОграничиватьДоступНаУровнеЗаписей в настройках программы. Если флаг "Ограничивать доступ на уровне записей" выключен в интерфейсе администрирования, RLS работать не будет, несмотря на все настройки в коде.Таким образом, для успешной реализации ограничения доступа необходимо не только правильно составить текст условия в шаблоне, соблюдая количество параметров, но и учитывать архитектурные особенности БСП, такие как режим производительности и механизмы объединения прав доступа.