Зачем нужно ограничение RLS на право Добавление в 1С:Документооборот

← На главную

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

Пример ограничения RLS на право Добавление

Рассмотрим типовой шаблон ограничения, накладываемый на документ, например, Отсутствие в базовой роли БазовыеПраваДокументооборот:


#Если &ДокументооборотИспользоватьОграниченияПравДоступа #Тогда
ТаблицаДокумента ИЗ Документ.Отсутствие КАК ТаблицаДокумента
    ГДЕ ТаблицаДокумента.Автор = &ТекущийПользователь
#КонецЕсли

Проанализируем ситуацию: в модуле объекта документа в процедуре ОбработкаЗаполнения или ПередЗаписью уже может присутствовать принудительная инициализация реквизита значением текущего пользователя сеанса. Выясним причину, почему разработчики конфигурации дополнительно дублируют это условие на уровне прав.

Архитектурные причины дублирования проверки в RLS

Существует несколько ключевых факторов, требующих контроля прав непосредственно на уровне СУБД:

Защита ядра базы данных от внешних воздействий и обхода интерфейса. Прикладной код формы и событий модуля объекта выполняется в штатном сценарии интерактивной работы. Однако объект может создаваться программно: через внешние обработки, расширения конфигурации, механизмы интеграции (REST API, Web-сервисы, HTTP-сервисы, COM-соединения). Ограничение RLS срабатывает на самом низком уровне транзакции записи СУБД и гарантирует, что сторонний код не сможет записать документ с произвольным значением реквизита Автор от имени обычного пользователя.
Поддержка механизма делегирования прав и замещения. В 1С:Документооборот действует развитая система передачи полномочий. Базовое условие Автор = &ТекущийПользователь гарантирует, что рядовой сотрудник не сможет сформировать документ от имени коллеги без явно выданных прав замещения или делегирования. Для оформления документов «за другого» требуются дополнительные роли или расширенный контекст прав.
Целостность матрицы доступа. В прикладных решениях на базе Библиотеки стандартных подсистем (БСП) права на дальнейшее чтение и изменение созданного документа часто привязаны к его автору. Если бы RLS на добавление отсутствовал, пользователь мог бы программно записать документ с чужим автором, после чего сразу потерял бы доступ к нему или переложил ответственность за действие на другого сотрудника.

Особенности сложения прав нескольких ролей

Разберем случай, когда пользователю удается создать документ и указать другого сотрудника, несмотря на наличие ограничения в базовой роли. В платформе 1С права доступа по назначенным пользователю ролям объединяются по правилу логического ИЛИ (дизъюнкция прав):

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

Работа синхронизации и фоновых обменов

Рассмотрим, как данное ограничение влияет на интеграционные процессы и планы обмена. При выполнении регламентных заданий или обменов данными (РИБ, синхронизация данных, веб-сервисы):

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

Влияние на производительность СУБД

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