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