Как перенести ограничения доступа из модуля менеджера в роль в БСП 3.1?

← На главную

При переходе на новые версии Библиотеки стандартных подсистем (БСП), начиная с ветки 3.1, разработчики часто сталкиваются с изменением парадигмы настройки прав доступа (RLS). Основная сложность заключается в том, что теперь логика ограничения описывается в модуле менеджера объекта, а в роли вставляется лишь шаблон. Разберем подробно, как правильно связать код в модуле менеджера с настройками в роли, и как автоматизировать этот процесс.

Архитектура управления доступом: Производительный vs Стандартный режим

Для начала проанализируем, почему в современных конфигурациях 1С текст в ролях стал выглядеть гораздо проще. В БСП реализовано два основных режима работы ограничений:

Стандартный режим: Традиционный подход, где в роли прописывается сложный запрос на языке SQL/1С (шаблоны типа #ПоЗначениям). Система выполняет эти условия при каждом обращении к базе данных.
Производительный режим: Новый подход, при котором права рассчитываются заранее и сохраняются в специальные служебные таблицы — «Ключи доступа». В ролях при этом используется максимально простой шаблон, который лишь дает команду системе обратиться к этим рассчитанным таблицам.

Рассмотрим ситуацию, описанную в теме: автор видит пустой шаблон #ДляОбъекта("") и не понимает, куда делась логика из модуля менеджера. В производительном режиме это нормальное поведение. Пустые кавычки означают, что система должна использовать все настройки, которые вы указали в процедуре ПриЗаполненииОграниченияДоступа модуля менеджера объекта.

Настройка логики в модуле менеджера

Выясним, как должна выглядеть процедура в модуле менеджера. Именно здесь мы описываем, какие поля объекта (или его табличных частей) влияют на доступ. Посмотрим на пример реализации для документа, где доступ ограничен по организации и номенклатуре в табличной части:


Процедура ПриЗаполненииОграниченияДоступа(Ограничение) Экспорт

	Ограничение.Текст =
		"РазрешитьЧтениеИзменение
		|ГДЕ
		|	ЗначениеРазрешено(Организация)
		|	И ДляВсехСтрок(ЗначениеРазрешено(Товары.Номенклатура))";

КонецПроцедуры

В этом коде мы используем специальные конструкции БСП. Например, ДляВсехСтрок означает, что пользователю будет разрешен доступ к документу только в том случае, если у него есть права на всю номенклатуру, указанную в табличной части Товары. Если хотя бы одна позиция запрещена — документ не откроется.

Как получить текст для вставки в роль автоматически

Если вам все же необходимо поддерживать стандартный режим (например, для совместимости или при работе в специфических условиях), писать сложные конструкции типа #ПоЗначениямРасширенный вручную крайне трудно. Рассмотрим, как заставить БСП саму сгенерировать этот текст.

Многие используют отчет ПроверкаВнедренияБСП.epf, но он часто выдает лишь пустой шаблон. Причина кроется в текущих настройках системы. Чтобы отчет выдал полный текст ограничения для роли, выполните следующие шаги:

Перейдите в настройки программы (или воспользуйтесь консолью кода) и временно переключите режим работы управления доступом в состояние «Стандартный и производительный».
Запустите отчет ПроверкаВнедренияБСП.epf (он обычно находится в составе дистрибутива БСП).
Выберите проверку подсистемы «Управление доступом» и запустите её в режиме исправления.
Теперь система, видя необходимость поддержки стандартного режима, проанализирует ваш код в модуле менеджера и сформирует готовый блок текста для вставки в роль.

Этот блок будет выглядеть примерно так:


#Если &ОграничениеДоступаНаУровнеЗаписейУниверсально #Тогда
#ДляОбъекта("")
#Иначе
#ПоЗначениямРасширенный("Документ.МойДокумент", "", "", "", "", "Организации", "Т.Организация", ...)
#КонецЕсли

Разбор работы шаблона #ДляОбъекта("")

Проанализируем, почему в 90% случаев в производительном режиме нам достаточно пустых кавычек. Когда платформа встречает шаблон #ДляОбъекта(""), она выполняет следующие действия:

Проверяет, включено ли ограничение доступа в константах системы.
Ищет в служебных таблицах БСП информацию о том, какие «группы доступа» имеют отношение к данному конкретному объекту (ссылке).
Сопоставляет текущего пользователя с этими группами.

Если в кавычках ничего не указано, БСП берет описание из метаданных, которые она собрала при обновлении информационной базы. Если же вы укажете поля вручную, например #ДляОбъекта("Организация"), это может потребоваться только в редких случаях для переопределения стандартного поведения, но для типового использования БСП рекомендует оставлять кавычки пустыми.

Сложные случаи: Ограничения по табличным частям

Рассмотрим ситуацию из сообщения №9, где автор столкнулся с огромным запросом. При использовании логики «Для всех строк» в стандартном режиме (RLS), система вынуждена генерировать подзапросы для проверки отсутствия запрещенных значений. Это выглядит устрашающе:


"И НЕ ЛОЖЬ В (
  ВЫБРАТЬ ПЕРВЫЕ 1 ЛОЖЬ
  ИЗ Документ.Баланс.Статьи КАК Т1
  ГДЕ Т.Ссылка = Т1.Ссылка И НЕ (...)"

Важное замечание: Именно из-за таких монструозных запросов 1С и внедрила «Производительный режим». В производительном режиме вся эта логика превращается в одну простую проверку по таблице ключей, что значительно ускоряет работу системы (особенно при проведении документов и формировании отчетов).

Порядок действий при изменении ограничений

Подведем итог и составим пошаговый алгоритм действий программиста при изменении условий доступа к объекту:

Вносим изменения в модуль менеджера: Корректируем процедуру ПриЗаполненииОграниченияДоступа. Добавляем новые поля или табличные части.
Обновляем вспомогательные данные: Запускаем в пользовательском режиме обработку «Обновление параметров системы» или используем программный вызов Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанные(). Это нужно, чтобы БСП «увидела» изменения в коде менеджера.
Обновляем роли: Если вы работаете только в производительном режиме, убедитесь, что в роли на права «Чтение», «Добавление» и «Изменение» стоит шаблон #ДляОбъекта("").
Тестируем: Используйте профили групп доступа, чтобы убедиться, что ограничения отрабатывают корректно. Помните, что для администратора RLS не действует.

Таким образом, автоматизация «конвертации» заключается не в поиске внешней обработки-транслятора, а в правильном использовании встроенных инструментов проверки внедрения БСП и понимании того, что в современном RLS основной упор сделан на предварительный расчет прав через ключи доступа, а не на сложные SQL-инструкции внутри ролей.