Как в 1С настроить RLS, чтобы документ был виден пользователям другой организации?

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

Метод 1. Добавление дополнительного реквизита доступа

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

Рассмотрим по шагам:

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

Этот способ хорош тем, что он «прозрачен» для платформы и не требует сложных запросов к регистрам. Однако стоит помнить, что использование условия ИЛИ в запросах RLS на очень больших объемах данных может привести к замедлению работы, поэтому убедитесь, что оба поля индексированы.

Метод 2. Использование расширенных шаблонов БСП

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

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

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

В данном примере мы видим использование макроса #ПоЗначениямРасширенный. Это позволяет системе гибко комбинировать права доступа. Если пользователь имеет доступ к организации И к одному из складов (отправителю ИЛИ получателю), документ станет видимым.

Метод 3. Создание отдельного регистра исключений

В ситуациях, когда логика доступа очень сложная и её невозможно описать простым добавлением реквизита, проанализируем вариант с регистром сведений. Мы создаем специальный регистр (например, ДоступныеДокументыПользователей), куда программно записываем пары «Документ — Пользователь» или «Документ — Организация».

Выясним преимущества этого подхода:

1. Гибкость: Вы можете давать доступ к конкретному документу конкретному человеку, не меняя структуру самого документа.
2. Динамичность: Права можно предоставлять на время или по выполнению определенных условий.

В шаблоне RLS в этом случае прописывается связь (JOIN) с этим регистром. Если запись в регистре существует — доступ разрешен.

Метод 4. Работа с Универсальным ограничением доступа (БСП 3.0+)

Современные версии 1С и БСП используют так называемый «производительный RLS». В этом режиме права не вычисляются каждый раз при запросе, а кэшируются в регистре КлючиДоступаКОбъектам. Если вы изменили логику доступа (добавили реквизит или изменили шаблон), важно правильно зарегистрировать эти изменения в программном коде.

Разберем, что нужно сделать в модуле менеджера объекта. Необходимо найти или создать процедуру ПриЗаполненииОграниченияДоступа. Рассмотрим пример кода:

Процедура ПриЗаполненииОграниченияДоступа(Ограничение) Экспорт
    Ограничение.Текст =
    "РазрешитьИзменениеУровняГруппДоступа = Ложь;
    |УсловиеДоступаПоОрганизации(Т.Организация);
    |УсловиеДоступаПоОрганизации(Т.ДополнительнаяОрганизация)";
КонецПроцедуры

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

Важные нюансы и рекомендации

Проанализируем несколько критических моментов, которые помогут избежать ошибок:

• Модуль объекта и менеджера: Помните, что при использовании БСП недостаточно просто поменять RLS в метаданных. Нужно обязательно проверить программную логику в модулях, иначе система может «затереть» ваши настройки при обновлении или пересчете прав.
• Функции в шаблонах: Старайтесь не использовать сложные вложенные запросы внутри RLS. Это основная причина деградации производительности в крупных информационных базах.
• Привилегированный режим: Если доступ нужен только для выполнения какой-то одной операции (например, программная проверка остатков по чужой организации), рассмотрите возможность выноса этого кода в Привилегированный модуль вместо расширения прав RLS. Это сохранит чистоту прав доступа и защитит данные от случайного просмотра пользователями.

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