Как в 1С:ERP разделить права RLS на чтение и редактирование по объектам

При переходе на 1С:ERP с конфигурации 1С:УПП специалисты часто сталкиваются с вопросом настройки ограничений на уровне записей (RLS). В УПП настройка была интуитивной: в специальной форме для конкретного пользователя или группы пользователей выбирался объект (например, склад) и флажками указывались доступные операции — Только чтение или Редактирование.

В 1С:ERP механизм подсистемы Управление доступом Библиотеки Стандартных Подсистем (БСП) устроен принципиально иначе. Выясним, почему старый подход не работает напрямую и как правильно настроить раздельный доступ к данным на чтение и изменение.

Архитектурные отличия RLS в УПП и 1С:ERP

Проанализируем ключевые архитектурные различия между конфигурациями:

1. Прямые ограничения против ключей доступа: В УПП условия RLS встраивались непосредственно в текст запросов ролей с обращением к регистрам прав. В ERP используется оптимизированный механизм ключей доступа (регистры сведений КлючиДоступаКОбъектам, КлючиДоступаКРегистрам, ТаблицыГруппДоступа). Права рассчитываются заранее на объект целиком на основании его реквизитов.
2. Логика объединения прав: В БСП действует принцип объединения разрешений по логическому ИЛИ (дизъюнкция). Если пользователю назначено несколько профилей групп доступа, итоговый доступ расширяется.
3. Отсутствие флагов операций внутри профиля: В профиле групп доступа ERP указываются только виды доступа и разрешенные или запрещенные значения. Сама логика того, что разрешено делать (читать или менять), определяется составом ролей, входящих в профиль.

Способ 1. Разделение прав через комбинацию ролей и профилей групп доступа

Разберем базовый способ разделения прав на чтение и запись, заложенный разработчиками БСП. Чтобы предоставить пользователю возможность просматривать документы по одним складам, а редактировать — только по другим, выполним следующие шаги:

1. Создание роли на чтение: Создаем роль (например, ЧтениеДокументовПоСкладам), в которой для нужных документов установлены только права Чтение и Просмотр. Права на добавление, изменение и удаление оставляем выключенными.
2. Создание роли на изменение: Создаем роль (например, ИзменениеДокументовПоСкладам), в которой включены права Чтение, Просмотр, Вставка, Изменение и проведение.
3. Формирование профилей групп доступа:
   1. Создаем профиль Просмотр документов (по складам), куда добавляем первую роль.
   2. Создаем профиль Редактирование документов (по складам), куда добавляем вторую роль.
4. Назначение групп доступа: Создаем две группы доступа для пользователя. В группе на просмотр указываем общий список складов (для чтения), а в группе на редактирование — только те склады, по которым разрешено оформлять и проводить документы.

Благодаря дизъюнкции прав пользователь получит доступ к просмотру всех указанных складов, но изменить сможет только те записи, для которых выполняются условия роли на изменение.

Особенности работы со сложными документами и табличными частями

Рассмотрим подробнее сценарии, когда в одном документе фигурирует несколько объектов доступа (например, документ Перемещение товаров со складом-отправителем и складом-получателем или документы со складами в строках табличной части):

1. Несколько реквизитов в шапке: В типовых шаблонах БСП для операции Чтение обычно применяется условие ИЛИ (документ виден, если разрешен хотя бы один из складов). Для операций Изменение и проведения требуется соблюдение условия И (пользователь обязан обладать правом на редактирование обоих складов — и отправителя, и получателя).
2. Склады в табличных частях: Построчный RLS при выводе в динамические списки не накладывается из соображений производительности. Механизм БСП при записи объекта формирует массив всех встречающихся складов и рассчитывает составной ключ доступа. Документ будет доступен пользователю только при наличии прав на весь набор складов из табличной части.

Способ 2. Программный контроль через подписки на события

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

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

Процедура ПроверитьДоступКРедактированиюПередЗаписью(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт
    
    Если Источник.ОбменДанными.Загрузка Тогда
        Возврат;
    КонецЕсли;
    
    // Проверяем, включено ли ограничение для текущего пользователя
    Если Не ПользователиИнформационнойБазы.ТекущийПользователь().ЭтоАдминистратор() Тогда
        
        СписокРазрешенныхСкладов = ПолучитьСкладыНаИзменение(ПараметрыСеанса.ТекущийПользователь);
        
        Если СписокРазрешенныхСкладов.Найти(Источник.СкладОтправитель) = Неопределено Тогда
            Отказ = Истина;
            ВызватьИсключение "У вас нет прав на изменение документов по складу: " + Строка(Источник.СкладОтправитель);
        КонецЕсли;
        
    КонецЕсли;

КонецПроцедуры

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

Способ 3. Использование механизма «Даты запрета изменения»

Посмотрим на штатную альтернативу сложным RLS-настройкам — механизм Даты запрета изменения данных в 1С:ERP. Он позволяет накладывать запрет на запись объектов с детализацией по разделам и объектам справочника Склады:

1. Открываем раздел НСИ и администрирование → Настройка пользователей и прав → Даты запрета изменения.
2. Включаем настройку и выбираем вариант детализации По пользователям и объектам.
3. Для конкретного пользователя или группы пользователей выбираем нужный склад и устанавливаем дату запрета в значение Конец текущего дня или произвольную будущую дату.

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