Как настроить ограничение доступа по ответственному в 1С:ЗУП 3.1 с помощью шаблона #ПоЗначениям

При настройке прав доступа в конфигурациях на базе Библиотеки стандартных подсистем (БСП), таких как 1С:Зарплата и управление персоналом 3.1, разработчики часто сталкиваются с необходимостью реализовать механизм RLS (Record Level Security). Типичная задача — сделать так, чтобы рядовой пользователь или руководитель видел только те документы, в которых он указан как ответственный, либо документы своих подчиненных.

В этой статье мы подробно разберем, как использовать стандартный шаблон #ПоЗначениям для решения этой задачи, проанализируем синтаксис параметров и выясним, почему пустые значения в поле «Ответственный» ведут себя иначе, чем в поле «Организация».

Использование шаблона #ПоЗначениям для ограничения по пользователям

Шаблон #ПоЗначениям является универсальным инструментом БСП, который позволяет не писать сложные SQL-подобные запросы в конструкторе ограничений доступа, а использовать предопределенную логику. Рассмотрим ситуацию: нам нужно ограничить чтение документа ПрогулНеявка так, чтобы система проверяла права по Организации, Физическому лицу и Ответственному.

Для реализации ограничения по полю «Ответственный», нам необходимо передать в шаблон соответствующий вид доступа и имя поля. Разберем правильный синтаксис вызова шаблона:

#ПоЗначениям( 
    "Документ.ПрогулНеявка",
    "Чтение",
    "",
    "Организации", "Организация", 
    "ГруппыФизическихЛиц", "ФизическоеЛицо", 
    "Пользователи", "Ответственный", 
    "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "" 
)

Давайте проанализируем структуру этого вызова:

1. "Документ.ПрогулНеявка" — целевой объект метаданных, на который накладывается ограничение.
2. "Чтение" — право, для которого настраивается RLS.
3. "Организации", "Организация" — пара «Вид доступа» и «Поле объекта». Здесь система проверяет, разрешена ли пользователю конкретная организация, указанная в документе.
4. "Пользователи", "Ответственный" — именно эта вставка отвечает за ограничение по автору или ответственному лицу. Вид доступа «Пользователи» должен быть предварительно включен в профиле групп доступа.

Проблема пустых значений в поле Ответственный

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

Выясним причину такого поведения. В БСП логика проверки пустых ссылок (ЗНАЧЕНИЕ(Справочник.Пользователи.ПустаяСсылка)) жестко завязана на то, как сформированы таблицы прав. Для справочника Пользователи система обычно требует явного указания соответствия. Если поле не заполнено, запрос RLS просто не находит запись в регистре сведений ПраваРолейПользователей (или аналогичных внутренних таблицах), и доступ отклоняется.

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

Как разрешить просмотр документов с пустым ответственным

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

1. Использование расширенного шаблона: В современных версиях БСП существует шаблон #ПоЗначениямРасширенный. Он позволяет более гибко настраивать логику «ИЛИ», добавляя условия для пустых значений.
2. Ручная правка текста запроса: Если типовой шаблон не справляется, мы можем добавить условие непосредственно в текст ограничения в конфигураторе. Например:
   Скопировать код

   
   ГДЕ (Ответственный = ЗНАЧЕНИЕ(Справочник.Пользователи.ПустаяСсылка))
       ИЛИ (&НомерПараметраВШаблоне...)
   

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

Оптимизированный (производительный) RLS и его отладка

Рассмотрим ситуацию, когда шаблон написан верно, но ограничения работают некорректно или сильно замедляют систему. Начиная с версии платформы 8.3.12, 1С активно использует «Производительный RLS».

Проанализируем, как это влияет на нашу задачу:

• Данные о правах кэшируются в специальных служебных таблицах.
• Если вы изменили настройки прав в пользовательском режиме (например, добавили нового пользователя в группу доступа), эти изменения могут вступить в силу не мгновенно.
• Для форсирования обновления можно запустить регламентное задание «Обновление прав доступа».

Для отладки сложных шаблонов, где текста слишком много и он трудночитаем, рекомендуем использовать консоль запросов с поддержкой RLS. Это позволит вам увидеть итоговый WHERE (ГДЕ) фрагмент, который платформа добавляет к каждому запросу. Если в итоговом SQL-запросе вы видите конструкцию, отсекающую NULL или EmptyRef по полю Ответственный, значит, логика шаблона требует расширения.

Итоги настройки

Подведем итог: для настройки ограничения по ответственному в ЗУП 3.1 мы используем вставку "Пользователи", "Ответственный" в стандартный шаблон. Помните, что вид доступа «Пользователи» должен быть добавлен в соответствующий профиль групп доступа, а для работы с пустыми значениями может потребоваться использование расширенных шаблонов или доработка логики заполнения документов. Для контроля действующих настроек RLS у пользователей и профилей подойдёт отчет по ограничениям пользователей и группам доступа.

Такой подход позволяет гибко настраивать видимость данных, обеспечивая конфиденциальность информации о сотрудниках и их начислениях в рамках конкретных рабочих групп или отделов. В качестве альтернативы ручному программированию RLS можно использовать подсистему для настройки прав доступа к объектам с помощью отборов.