Как настроить RLS в УТ 10.3, чтобы ограничения не блокировали РИБ-обмен и проведение документов?

При внедрении механизмов ограничения доступа на уровне записей (RLS) в типовых конфигурациях, таких как УТ 10.3, часто возникают конфликты между правами пользователя и системными процессами, требующими доступа к широкому спектру данных. Рассмотрим подробнее, почему возникают ошибки при обмене РИБ и проведении, и разберем проверенные способы решения этой задачи.

Понимание природы проблемы

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

Решение 1: Использование привилегированного режима для проведения

Если проблема возникает именно в момент проведения документа, когда логика партионного учета требует доступа к данным, скрытым RLS, оптимальным решением является использование привилегированного режима. Этот режим позволяет временно «забыть» о правах текущего пользователя и выполнить операции с данными без ограничений.

Для реализации этого метода следуйте инструкции:

1. Создайте привилегированный общий модуль или используйте существующий, если логика проведения вынесена туда.
2. Если вы используете обычные формы, вызов УстановитьПривилегированныйРежим(Истина) можно осуществлять непосредственно в коде модуля проведения, где выполняется запись движений.

Посмотрим на пример программной реализации:

// Включаем привилегированный режим перед выполнением критической операции
УстановитьПривилегированныйРежим(Истина);

Попытка
    // Выполняем проведение документа или списание партий
    ДокументОбъект.Записать(РежимЗаписиДокумента.Проведение);
Исключение
    // Обработка ошибок
КонецПопытки;

// Обязательно возвращаем режим в исходное состояние
УстановитьПривилегированныйРежим(Ложь);

Решение 2: Разделение прав для РИБ-обмена

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

Создайте отдельную учетную запись для обмена.

• Создайте пользователя с полными правами, предназначенного исключительно для автоматизированных задач (обменов).
• В настройках обработки обмена укажите этого пользователя или настройте запуск обмена через регламентные задания на стороне сервера.
• Для такого пользователя RLS не требуется, что позволит беспрепятственно загружать и выгружать любые данные РИБ без конфликтов доступа.

Почему не стоит переключать параметры сеанса в RLS?

Рассмотрим, почему идея использования параметров сеанса в шаблонах ограничений считается «антипаттерном»:

• Производительность: Платформа кэширует результаты проверки прав доступа. Если вы меняете параметр сеанса, участвующий в шаблоне RLS, кэш инвалидируется и пересчитывается заново для всех пользователей. В высоконагруженных системах это приведет к «зависаниям» всей базы данных.
• Надежность: Использование обработчиков ожидания для переключения параметров ненадежно — если процесс проведения прервется по ошибке, параметр может остаться в состоянии «Истина», что создаст дыру в безопасности.

Итоговые рекомендации

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

1. Для проведения: Используйте УстановитьПривилегированныйРежим(Истина) внутри привилегированных общих модулей или непосредственно в блоках кода, отвечающих за запись движений. Это позволит системе выполнить расчеты по партионному учету, несмотря на ограничения RLS.
2. Для обмена: Используйте выделенного пользователя с полными правами. В 1С:Управление торговлей 10.3 обмен данными — это техническая задача, требующая доступа ко всему объекту (документу), поэтому попытка применить RLS к процессу обмена в корне неверна.
3. Архитектурный подход: Всегда стремитесь к тому, чтобы логика, требующая повышенных прав (списание партий, проведение, обмен), была изолирована от пользовательского интерфейса, работающего с RLS.

Используя эти методы, вы обеспечите корректное проведение документов и стабильный обмен данными, сохранив при этом безопасность и целостность настроек RLS для обычных пользователей.