Как настроить ограничение прав доступа (RLS) по подразделениям для заказов покупателей в 1С:УПП?

← На главную

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

Анализируем причину отсутствия RLS в типовых ролях

Рассмотрим ситуацию: при использовании типовой роли МенеджерПоЗаказам мы видим, что в шаблонах ограничений прописаны проверки по Контрагентам, Организациям и Складам, но поле Подразделение игнорируется. Проанализируем типичный фрагмент кода RLS для этого документа:


#Если &ИспользоватьОграничениеПоКонтрагенты ИЛИ &ИспользоватьОграничениеПоОрганизации ИЛИ &ИспользоватьОграничениеПоСклады #Тогда
ТекущаяТаблица
ИЗ
    #ТекущаяТаблица КАК ТекущаяТаблица
...
ГДЕ
    (НЕ 1 В (ВЫБРАТЬ ПЕРВЫЕ 1 1 ИЗ РегистрСведений.НазначениеВидовОбъектовДоступа ...))
#КонецЕсли

Выясним причину такого решения архитекторов 1С. В УПП поле Подразделение присутствует практически в каждом первичном документе и регистре. Если включить RLS по этому разрезу для всех объектов, это создаст колоссальную нагрузку на SQL-сервер. Каждая проверка прав — это вложенный запрос с множественными соединениями (LEFT JOIN). При большом объеме данных (десятки и сотни тысяч заказов) время открытия списка документов может увеличиться в несколько раз. Именно поэтому в «тяжелых» документах приоритет был отдан более критичным разрезам: организациям и контрагентам.

Разбираем эффект «Объект не найден» в колонке подразделения

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

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

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

Внедрение ограничения по подразделениям по аналогии с регистрами

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


#Если &ИспользоватьОграничениеПоКонтрагенты ИЛИ &ИспользоватьОграничениеПоОрганизации ИЛИ &ИспользоватьОграничениеПоПодразделения #Тогда
ТекущаяТаблица
ИЗ
    #ТекущаяТаблица КАК ТекущаяТаблица
    ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ РАЗЛИЧНЫЕ СоставГруппы.Ссылка КАК ГруппаПользователей
        ИЗ Справочник.ГруппыПользователей.ПользователиГруппы КАК СоставГруппы
        ГДЕ СоставГруппы.Пользователь = &ТекущийПользователь) КАК ГруппыПользователей
    ПО (ИСТИНА)
ГДЕ
    (НазначениеВидовОбъектовДоступа.ВидОбъектаДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Подразделения)
    И ТекущаяТаблица.#Параметр(3) = НастройкиПравДоступаПользователей.ОбъектДоступа)
#КонецЕсли

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

Параметр(1) — Контрагент;
Параметр(2) — Организация;
Параметр(3) — Подразделение.

Рассмотрим по шагам процесс доработки:

Откройте нужную роль (например, МенеджерПоПродажам) в конфигураторе.
Найдите объект ЗаказПокупателя и перейдите на вкладку Права.
Для права Чтение выберите ограничение доступа к данным.
Добавьте условие по подразделению, используя системный параметр &ИспользоватьОграничениеПоПодразделения. Это позволит включать и выключать ограничение через константы в режиме 1С:Предприятие без изменения кода.

Проблема производительности и пути оптимизации

Крайне важно осознавать риски. Как отмечают опытные администраторы баз данных, при достижении критического объема документов (например, более 50 000 записей в таблице), сложные RLS-запросы начинают «тормозить». Это связано с тем, что SQL-оптимизатор не всегда может эффективно построить план запроса с вложенными условиями на права доступа.

Для минимизации падения производительности выполним следующие рекомендации:

Индексация: Убедитесь, что поле Подразделение во всех документах, где внедряется RLS, включено в состав индексов. Если индекса нет, система будет выполнять Table Scan (полное сканирование таблицы), что приведет к блокировкам.
Использование групп доступа: Старайтесь ограничивать доступ не по конкретным элементам справочника Подразделения, а через Группы доступа (если это предусмотрено логикой), чтобы уменьшить количество записей в регистре НастройкиПравДоступаПользователей.
Альтернативные методы: Если жесткая безопасность на уровне СУБД не обязательна, рассмотрите возможность фильтрации данных в Форме списка через ПриОткрытии или УстановитьОтбор. Это не закроет доступ к данным программно, но скроет лишние записи от глаз пользователя без нагрузки на RLS.

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

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

← На главную