Как ограничить видимость заказов в 1С:УТ 11.4 и заставить RLS работать корректно

Одной из самых распространенных задач в конфигурации «1С:Управление торговлей 11.4» является настройка прав доступа таким образом, чтобы менеджеры видели только свои заказы или заказы своей группы. Несмотря на наличие типовых механизмов, администраторы часто сталкиваются с ситуацией, когда, несмотря на все настройки, пользователь продолжает видеть «лишние» документы. Разберем детально, как устроена система разграничения прав на уровне записей (RLS) и как найти причину избыточной видимости данных.

Принцип аддитивности прав: почему менеджер видит всё?

Прежде чем приступать к коду или настройкам групп доступа, необходимо осознать фундаментальный принцип работы системы прав в 1С: права суммируются по принципу «ИЛИ». Рассмотрим ситуацию: у пользователя есть две роли. Первая роль МенеджерТолькоСвоиДокументы содержит жесткое ограничение RLS, разрешающее чтение только тех заказов, где он является ответственным. Вторая роль — это любая стандартная роль (например, ЧтениеЗаказовКлиентов или даже роль, входящая в состав прав «Самообслуживание»), в которой ограничение RLS не прописано (стоит значение ГДЕ ИСТИНА).

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

Шаг 1. Анализ текущих прав пользователя

Проанализируем ситуацию с помощью встроенных инструментов. Чтобы не гадать, какая именно роль «светит» заказы, воспользуемся отчетом «Анализ прав доступа». Его можно найти в разделе Администрирование — Настройки пользователей и прав.

1. В отчете выберите конкретного пользователя.
2. В качестве объекта укажите документ ЗаказКлиента.
3. Сформируйте отчет и внимательно посмотрите на колонку с ролями.

Вы увидите список всех ролей, которые дают право на «Чтение» или «Просмотр». Если в списке есть роль, у которой в колонке «Ограничение доступа» пусто или указано «Нет», значит, именно эта роль является причиной проблемы. Вам необходимо либо исключить эту роль из профиля пользователя, либо добавить в неё шаблон ограничения доступа.

Шаг 2. Настройка типового механизма «Группы доступа партнеров»

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

Логика работы здесь строится от обратного: мы ограничиваем доступ к Контрагенту (Партнеру), и, как следствие, система скрывает все его документы (Заказы, Накладные и т.д.).

Разберем по шагам настройку этого механизма:

1. Перейдем в НСИ и Администрирование — Настройка пользователей и прав — Ограничение доступа на уровне записей. Установим этот флаг.
2. Создадим Группы доступа партнеров (например, «Отдел продаж Север», «VIP-клиенты»).
3. В карточке каждого Партнера на вкладке «Администрирование» укажем соответствующую группу доступа.
4. В Профиле групп доступа (который назначен менеджеру) перейдем на вкладку «Ограничения доступа».
5. Для вида доступа «Группы партнеров» установим значение «Все запрещены, кроме...» и выберем нужные группы.

Важно помнить: если поле «Партнер» в заказе не заполнено или партнер не входит ни в одну ограниченную группу, документ может остаться видимым (в зависимости от настроек по умолчанию).

Шаг 3. Использование нетиповой роли с RLS по ответственному

Если в вашей конфигурации уже существует роль МенеджерТолькоСвоиДокументы, проанализируем, как она должна быть настроена в конфигураторе. Обычно ограничение накладывается на право Чтение объекта Документ.ЗаказКлиента.

Рассмотрим пример шаблона ограничения, который часто используется в таких случаях:

#Если &ОграничениеДоступаНаУровнеЗаписейУниверсальное #Тогда
    #ДляОбъекта("")
#Иначе
    ГДЕ Ответственный = &АвторизованныйПользователь
    ИЛИ Автор = &АвторизованныйПользователь
#КонецЕсли

В этом коде мы проверяем, совпадает ли текущий пользователь системы с тем, кто указан в поле Ответственный или Автор документа. Однако стоит учитывать, какой режим работы RLS выбран в настройках вашей базы.

Шаг 4. Режимы работы RLS: Производительный vs Стандартный

В версии 11.4 система может работать в двух режимах. Проверим это в разделе НСИ и Администрирование — Настройки пользователей и прав — Ограничение доступа на уровне записей.

1. Стандартный режим. Запросы RLS выполняются «на лету» при каждом обращении к базе. Это медленно, но изменения в правах вступают в силу мгновенно.

2. Производительный режим. Система использует заранее рассчитанные таблицы прав (регистры НаборыЗначенийДоступа). Это работает значительно быстрее на больших объемах данных.

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

• Данные в регистрах не обновлены. Если вы изменили ответственного в заказе, но фоновое задание по обновлению прав еще не запустилось, старый менеджер все еще будет видеть заказ, а новый — нет.
• Сбой фонового задания. Проанализируем работу регламентного задания ОбновлениеДоступаНаУровнеЗаписей. Если оно завершилось с ошибкой, таблицы прав будут неактуальны.

Для принудительного обновления таблиц доступа в интерфейсе «Управление доступом» предусмотрена кнопка «Обновить». Она инициирует пересчет всех прав доступа для объектов.

Шаг 5. Поиск скрытых доработок

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

1. Модификации запроса динамического списка заказов.
2. Подписок на события, которые при записи документа меняют его «Ответственного» или «Группу доступа» программно.
3. Настроек «Общих модулей», где может быть прописана логика УстановитьПривилегированныйРежим(Истина), которая отключает проверку RLS в определенных формах.

Итоговые рекомендации по исправлению

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

1. Удалите у пользователя все «лишние» роли. Оставьте только те, что необходимы для работы, и убедитесь через отчет «Анализ прав доступа», что ни одна из них не дает неограниченное чтение.
2. Проверьте заполнение поля Ответственный. Если в вашей организации заказы создает один человек, а ведет другой, убедитесь, что RLS настроен именно по тому полю, которое должно определять владельца.
3. Используйте типовой механизм групп партнеров, если это возможно. Это наиболее стабильный путь в рамках поддержки конфигурации 1С:УТ 11.4.
4. Следите за регламентными заданиями. При использовании производительного RLS корректная работа фоновых процессов — залог правильного отображения данных.

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