Как в подчиненном узле РИБ ограничить видимость документов из центральной базы для определенных пользователей

← На главную

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

Почему правила обмена РИБ и контекст загрузки не решают задачу напрямую

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

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

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

Разберем основные практические варианты реализации ограничения доступа к документам в 1С:Управление торговлей 10.3.

Вариант 1. Настройка RLS по реквизиту «Ответственный» или «Автор»

Простейший способ разделения прав на уровне записей — ограничить чтение документов по полю Ответственный. В этом случае пользователь сможет видеть только те документы, в которых он указан в качестве ответственного лица.

Рассмотрим порядок настройки логики зацепки за ответственного:

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

Пример текста RLS для права на чтение документа:


ГДЕ Ответственный = &ТекущийПользователь
   ИЛИ НЕ &ИспользоватьОграничениеПоОтветственному

Важный нюанс: Чтобы менеджер видел ПКО, оформленный бухгалтером в ЦБ по его заказу, необходимо обеспечить копирование значения реквизита Ответственный из документа-основания (Заказа) в кассовый документ при его создании или при загрузке данных в ЦБ.

Вариант 2. Добавление реквизита источника создания объекта

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

Рассмотрим алгоритм реализации:

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

Пример кода в модуле объекта:


Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
	
	Если НЕ ОбменДанными.Загрузка Тогда
		Если ЭтоНовый() Тогда
			УзелСоздания = ПланыОбмена.ПолнотекстовыйПоиск.ЭтотУзел();
			ЛокальныйДокумент = Истина;
		КонецЕсли;
	КонецЕсли;

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

После заполнения реквизита настроим ограничение доступа RLS, где разрешим пользователям с ролью менеджера чтение только тех записей, у которых ЛокальныйДокумент = Истина или УзелСоздания = &ТекущийУзел.

Вариант 3. Программные отборы и блокировка открытия форм

В конфигурациях на обычных формах (таких как УТ 10.3) использование RLS со сложными подзапросами может приводить к снижению производительности при открытии журналов. Альтернативный путь — разработка специализированного рабочего места или отбор на уровне форм списков.

Проанализируем этапы реализации данного подхода:

В форме списка или журнала документов в событии ПриОткрытии программно устанавливается нестираемый отбор по ответственному или локальному признаку.
В событии ПередОткрытием формы самого документа выполняется проверка прав доступа на чтение конкретного объекта.

Пример кода проверки в форме документа:


Процедура ПередОткрытием(Отказ, СтандартнаяОбработка)
	
	Если НЕ РольДоступна("ПолныеПрава") Тогда
		Если Ответственный <> глЗначениеПеременной("гИмяТекущегоПользователя") Тогда
			Предупреждение("У вас нет прав на просмотр данного документа!");
			Отказ = Истина;
		КонецЕсли;
	КонецЕсли;

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

Вариант 4. Использование типового RLS по группам контрагентов

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

Если за каждым менеджером закреплен определенный список контрагентов (или папка в справочнике Контрагенты), включение типового ограничения прав по контрагентам автоматически скроет из списков менеджера все документы (включая пришедшие из ЦБ), оформленные по чужим клиентам. Бухгалтеру при этом назначаются права без ограничений по группам контрагентов.