Почему не работает RLS для журнала документов в расширении 1С и как это исправить

Настройка ограничений доступа на уровне записей (RLS — Record Level Security) в платформе 1С:Предприятие часто вызывает трудности у разработчиков. Особенно остро проблемы проявляются при попытке настроить RLS через механизм расширений или при работе с журналами документов в конфигурациях, построенных на базе Библиотеки стандартных подсистем (БСП). Разработчики нередко сталкиваются с ситуацией, когда даже самое жесткое условие ограничения (например, простое ГДЕ ЛОЖЬ) игнорируется платформой, и пользователь по-прежнему видит все документы в списке.

В этой статье мы подробно разберем, почему возникает такое поведение, как работает механизм сложения прав в платформе, и по шагам настроим работоспособное ограничение доступа для журнала документов в расширении.

Причина 1: Принцип сложения прав доступа (Логическое "ИЛИ")

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

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

Как решить эту проблему:

1. Выясните, какие именно роли назначены пользователю и дают доступ к целевому объекту.
2. Исключите эти роли из профиля групп доступа пользователя.
3. Если роль является типовой и ее нельзя просто так отобрать у пользователя, вам придется заимствовать эту роль в ваше расширение и в ней снять флаг «Чтение» (или переопределить RLS) для нужного журнала документов или входящих в него документов. Доступ к объекту должен остаться только через вашу новую специализированную роль с настроенным RLS.

Причина 2: Необходимость запуска обновления информационной базы

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

Для принудительного обновления и перестроения ключей доступа необходимо запустить конфигурацию в режиме Предприятия со специальным параметром запуска. Разберем этот шаг подробно:

1. Откройте настройки запуска вашей информационной базы в конфигураторе или в стартере 1С.
2. В поле «Параметры запуска» (ключ /C) добавьте следующую команду: /c ЗапуститьОбновлениеИнформационнойБазы
3. Запустите систему в режиме «1С:Предприятие» под пользователем с полными правами. Дождитесь завершения выполнения всех процедур обновления.
4. После выполнения этой процедуры система пересчитает кэш прав доступа, и новые правила RLS вступят в силу.

Причина 3: Особенности производительного (универсального) режима RLS в БСП

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

В этом случае платформа полностью игнорирует классический шаблон #ПоЗначениям. Вместо него система ожидает использования универсального шаблона #ДляОбъекта(""). Если написать только старый шаблон, RLS работать не будет или начнет вызывать ошибки времени выполнения (runtime-ошибки) при попытке обращения к базе данных.

Давайте посмотрим на пример правильного написания условия RLS, которое учитывает оба режима работы системы (совместимость со старым и новым RLS в БСП):

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

Для того чтобы универсальный RLS корректно заработал для вашего нового или заимствованного объекта в расширении, его также необходимо зарегистрировать в программных механизмах БСП:

1. В расширении найдите или переопределите общий модуль УправлениеДоступомПереопределяемый.
2. В процедуре ПриЗаполненииСписковСОграничениемДоступа добавьте ваш журнал документов в список контролируемых объектов:

Процедура ПриЗаполненииСписковСОграничениемДоступа(Списки) Экспорт
    Списки.Вставить(Метаданные.ЖурналыДокументов.Деньги, Истина);
КонецПроцедуры

После этого обязательно обновите информационную базу через ключ запуска /c ЗапуститьОбновлениеИнформационнойБазы.

Причина 4: Специфика применения RLS к журналам документов

При настройке прав на журналы документов разработчики часто допускают архитектурную ошибку: настраивают ограничения только на сами документы (например, Документ.ПоступлениеБезналичныхДенежныхСредств и Документ.СписаниеБезналичныхДенежныхСредств), забывая про сам журнал документов ЖурналДокументов.Деньги.

Рассмотрим, к каким последствиям это приводит:

• Пользователь открывает журнал документов.
• Поскольку на сам журнал ограничений нет, система считывает все записи журнала.
• Однако, при попытке отобразить данные конкретных документов (которые ограничены по RLS на уровне самих документов), система не может прочитать их реквизиты. В результате в журнале будут отображаться «пустые» строки, а вместо значений (например, контрагента или суммы) пользователь увидит надписи <Объект не найден...>.

Правило успешной настройки RLS для журналов: ограничения должны быть идентично настроены как на все входящие в журнал документы, так и на сам журнал документов.

При этом реквизит, по которому идет ограничение (например, Организация), обязательно должен быть добавлен в Графы журнала документов в конфигураторе, и для этого реквизита должно быть настроено сопоставление с аналогичными реквизитами всех входящих в журнал документов. Если этого не сделать, СУБД не сможет выполнить запрос RLS и выдаст ошибку.

Альтернативное решение: Собственный (самописный) запрос RLS

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

Разберем пример, как написать простое и надежное ограничение по организации без использования громоздких шаблонов:

ЖурналДокументов.Деньги ГДЕ Организация В 
    (ВЫБРАТЬ РазрешенныеОрганизации.Организация 
     ИЗ РегистрСведений.РазрешенныеОрганизации КАК РазрешенныеОрганизации 
     ГДЕ РазрешенныеОрганизации.Пользователь = &ПараметрСеанса.ТекущийПользователь)

Преимущества использования собственного запроса:

• Полный контроль над логикой работы запроса.
• Независимость от версий и настроек БСП в конкретной информационной базе.
• Простота отладки (запрос можно легко проверить в консоли запросов).

Недостатки:

• Возможное снижение производительности СУБД, так как шаблоны БСП оптимизированы под сложные схемы кэширования прав.
• При добавлении новых объектов или изменении структуры метаданных вам придется обновлять этот запрос вручную в вашей роли в расширении.

Мы проанализировали основные подводные камни при настройке RLS в расширениях 1С. Помните о золотом правиле: всегда проверяйте пересечение ролей у тестового пользователя и не забывайте запускать обновление базы данных для актуализации ключей доступа.