Как ограничить редактирование справочника Договоры контрагентов в 1С:УТ 10.3 при использовании RLS

← На главную

При настройке прав доступа на уровне записей (RLS) в конфигурации «Управление торговлей 10.3» специалисты часто сталкиваются с ситуацией, когда ограничения для справочника Контрагенты работают корректно, а подчиненный справочник ДоговорыКонтрагентов остается доступным для редактирования всем пользователям. Разберем подробно, почему так происходит, как работает механизм суммирования прав в 1С и как правильно настроить ограничения для подчиненных объектов.

Анализ механизма объединения ролей в 1С

Прежде чем приступать к написанию условий RLS, нам необходимо вспомнить фундаментальный принцип работы платформы 1С:Предприятие: права пользователя суммируются по принципу «ИЛИ». Это означает, что если пользователю назначено несколько ролей, и хотя бы в одной из них разрешено изменение объекта без ограничений, то никакие условия RLS в других ролях не смогут заблокировать это действие.

Проанализируем типичную ситуацию из практики. Пользователю назначены две роли:

Основная роль (например, «Менеджер по продажам») — здесь вы настроили RLS, который разрешает редактировать только «свои» договоры.
Типовая роль «Пользователь» — эта роль обязательна для входа в систему, но в типовой конфигурации УТ 10.3 она часто содержит базовые права на чтение и изменение справочника ДоговорыКонтрагентов без каких-либо условий RLS.

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

Шаг 1. Поиск «разрешающей» роли

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

Откройте список ролей пользователя в конфигураторе.
Для каждого справочника (например, ДоговорыКонтрагентов) проверьте колонку «Изменение».
Найдите все роли, где стоит галочка на этом праве.
Проверьте, установлены ли в этих ролях шаблоны ограничений.

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

Шаг 2. Настройка RLS для справочника Договоры контрагентов

Теперь разберем, как именно ограничить редактирование договоров, основываясь на владельце (контрагенте). В УТ 10.3 для этого предусмотрены типовые шаблоны. Проанализируем ситуацию: нам нужно, чтобы пользователь мог видеть все договоры, но изменять — только те, что принадлежат «его» контрагентам.

Для этого в конфигураторе на закладке «Ограничение доступа» для права Изменение справочника ДоговорыКонтрагентов мы должны прописать условие. Если используется стандартный механизм групп доступа контрагентов, код шаблона будет выглядеть так:

#КонтрагентВШапке("Владелец")

Этот шаблон автоматически разворачивается платформой в сложный запрос, который проверяет принадлежность владельца договора к группам доступа, разрешенным текущему пользователю. Рассмотрим подробнее, что происходит «под капотом»:

Система берет поле Владелец из таблицы договоров.
Обращается к справочнику Контрагенты и находит значение поля ГруппаДоступа.
Сверяет эту группу с регистром сведений НастройкаПравДоступаПользователей, где хранятся связки «Пользователь — Группа доступа — Вид права».

Шаг 3. Реализация сложной логики через запрос

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


ДоговорыКонтрагентов ГДЕ Владелец В (
    ВЫБРАТЬ
        Ссылка
    ИЗ
        Справочник.Контрагенты
    ГДЕ
        #КонтрагентВШапке("Ссылка")
)

Важный момент: если на право «Чтение» ограничений нет, пользователь будет видеть весь список. Но при попытке нажать кнопку «Записать» в карточке договора, система проверит условие для права «Изменение» и выдаст ошибку доступа, если условие не соблюдено.

Особенности работы с пустыми группами доступа

Проанализируем ситуацию, когда у контрагента не заполнена группа доступа. В типовой логике УТ 10.3 это может привести к двум результатам в зависимости от настроек программы:

Если в настройках параметров учета или константах не указано иное, пустая группа доступа часто трактуется как «доступ запрещен всем».
Это означает, что как только вы включаете RLS, вы обязаны заполнить группы доступа у всех объектов, иначе они «исчезнут» или станут недоступны для редактирования у всех пользователей, кроме полных прав.

Влияние на производительность системы

Важно помнить, что каждый настроенный RLS — это дополнительная нагрузка на SQL-сервер. Посмотрим, как это влияет на работу: при открытии списка договоров платформа фактически переписывает запрос к базе данных, добавляя к нему конструкцию WHERE (условие RLS).

Для оптимизации работы придерживайтесь следующих правил:

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

Заключение и выводы

Подводя итог, можно сказать, что решение проблемы «избыточного» редактирования в УТ 10.3 всегда кроется в аудите ролей. Если Контрагенты ограничиваются, а Договоры нет — значит, есть роль, дающая право на изменение договоров без условий.

Алгоритм исправления: нашли лишнее право в роли Пользователь -> установили там шаблон #КонтрагентВШапке("Владелец") -> проверили, что группы доступа у контрагентов заполнены корректно. После этих действий система начнет отрабатывать правила доступа согласованно для всей цепочки документов и справочников.