При работе с механизмом RLS (Row Level Security) в конфигурации «Управление производственным предприятием» (УПП) разработчики часто сталкиваются с парадоксальной ситуацией. После настройки ограничений на чтение по определенному измерению в регистре бухгалтерии Хозрасчетный, пользователи теряют возможность проводить документы. Платформа выдает ошибку «У пользователя недостаточно прав на исполнение операции над базой данных», а в Журнале регистрации фиксируется «Отказ в доступе» на чтение к объекту РегистрБухгалтерии.Журнал проводок (бухгалтерский учет).
Самое загадочное в этой ситуации — полное отсутствие в программном коде явных вызовов запросов или методов чтения из этого регистра в момент проведения. Разберем детально, почему так происходит и как решить эту проблему, сохранив работоспособность системы и логику разграничения прав.
Первым делом проанализируем, как устроена запись движений в 1С. Когда документ выступает регистратором, он не просто добавляет новые строки в таблицу базы данных. Происходит сложный процесс управления набором записей. Рассмотрим основные механизмы, которые инициируют неявное чтение:
Журнал проводок (бухгалтерский учет). Любая операция записи в регистр сопровождается проверками в таблице журнала. Ошибка в Журнале регистрации часто указывает именно на таблицу журнала, так как платформа обращается к ней для контроля уникальности записей и обеспечения целостности периодов.Хозрасчетный является балансовым, при записи каждой проводки платформа выполняет внутренний контроль двойной записи (Дебет = Кредит). Для актуализации итогов по счетам система считывает текущее состояние агрегатов и итогов. Если условия RLS наложены так, что текущие итоги становятся «невидимыми» для пользователя, платформа не может корректно рассчитать новые значения и выбрасывает исключение.Рассмотрим ситуацию с точки зрения свойств объекта метаданных. Если у документа ПриобретениеТоваровУслуг (ПТУ) или любого другого настроено автоматическое удаление движений, мы попадаем в ловушку RLS. Платформа генерирует внутренний SQL-запрос, который пытается сопоставить текущего пользователя с правами на записи, которые уже лежат в базе.
Посмотрим на пример логики, которая происходит «под капотом»:
// Платформа выполняет неявное действие перед выполнением кода ОбработкаПроведения
НаборЗаписей = РегистрыБухгалтерии.Хозрасчетный.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Регистратор.Установить(СсылкаНаДокумент);
НаборЗаписей.Прочитать(); // Вот здесь происходит сбой RLS на чтение!
НаборЗаписей.Очистить();
НаборЗаписей.Записать();
Даже если в модуле проведения вы установите Движения.Хозрасчетный.Записывать = Истина, этот механизм сработает автоматически. Единственный способ увидеть этот запрос — использование Технологического журнала, но, как правило, он покажет лишь SELECT к таблице регистра без привязки к конкретной строке модуля, так как это действие ядра платформы.
Существует несколько стратегий решения этой проблемы, в зависимости от того, насколько жестко вам нужно ограничить доступ.
Это самый распространенный метод. Если нам нужно, чтобы пользователь мог проводить документы (создавать записи), но не видел чужие проводки в отчетах, мы должны перенести логику записи в привилегированный модуль. Однако, для стандартного проведения в УПП этого может быть недостаточно, так как автоматическое удаление движений происходит до входа в процедуру ОбработкаПроведения.
Попробуем изменить подход к удалению движений:
ПередЗаписью или в самом начале ОбработкаПроведения вызовите процедуру очистки движений в привилегированном модуле.Пример кода в привилегированном модуле:
Процедура ОчиститьДвиженияПривилегированно(ДокументСсылка) Экспорт
УстановитьПривилегированныйРежим(Истина);
Набор = РегистрыБухгалтерии.Хозрасчетный.СоздатьНаборЗаписей();
Набор.Отбор.Регистратор.Установить(ДокументСсылка);
Набор.Записать(); // Пустой набор затрет старые записи без проверки прав RLS
КонецПроцедуры
Это более тонкая настройка прав доступа, которая часто выручает в подобных ситуациях. В 1С право Чтение отвечает за программный доступ к данным (в том числе для нужд платформы), а право Просмотр — за отображение этих данных в интерфейсе (списки, формы, отчеты).
Рассмотрим алгоритм настройки:
Хозрасчетный уберите RLS с права Чтение. Дайте это право без ограничений. Это позволит платформе беспрепятственно выполнять технические операции (удаление старых записей, проверку итогов).Важно: Помните, что право Чтение без RLS позволяет пользователю получить данные программно (например, через внешнюю обработку), если у него есть права на запуск внешних обработок. Оцените риски безопасности для вашей системы.
Если вы используете платформу версии 8.3.11, проанализируйте само условие запроса в RLS. На этой версии оптимизатор запросов иногда некорректно строил временные таблицы при наличии сложных соединений (JOIN) в условиях RLS.
Если ваше условие выглядит так:
Хозрасчетный ГДЕ Хозрасчетный.Организация В (ВЫБРАТЬ... ИЗ Справочник.Организации...)
Попробуйте упростить его или использовать параметры сеанса. Убедитесь, что поле, по которому идет ограничение (например, Организация), всегда заполнено. Если в регистре окажутся записи с NULL или Неопределено в этом поле, RLS может заблокировать доступ на чтение всего набора записей регистратора при попытке его перезаписи.
Проверьте настройку «Обновление вспомогательных данных». Хотя в УПП нет БСП в современном понимании, в последних версиях на обычных формах могли быть внедрены элементы подсистемы управления доступом. Запуск информационной базы с параметром /C ЗапуститьОбновлениеИнформационнойБазы иногда помогает пересчитать кэшированные права доступа, хотя в случае с самописным RLS это помогает редко.
Подведем итог: RLS на регистрах бухгалтерии — это сложный инструмент, требующий понимания жизненного цикла записи данных. В большинстве случаев проблема решается либо разрешением технического чтения (права без ограничений на Чтение, но с RLS на Просмотр), либо полным выносом операций с регистром в привилегированные модули с отказом от автоматического управления движениями документа.