Почему не работает RLS для контрагентов в 1С:КА 2.4 и как это исправить?

← На главную

Настройка ограничений доступа на уровне записей (RLS) в современных конфигурациях, таких как 1С:Комплексная автоматизация 2.4 или 1С:ERP, существенно отличается от старых версий систем. Часто администраторы и программисты сталкиваются с ситуацией, когда все флаги расставлены, группы доступа созданы, но пользователь продолжает видеть "запрещенные" данные. Рассмотрим детально, в чем могут быть причины и как пошагово наладить работу RLS.

Анализ первой причины: Полные права и их влияние

Первое, что необходимо проверить — это наличие у тестируемого пользователя роли ПолныеПрава. Разберем механизм работы платформы: RLS (Record Level Security) — это дополнительные условия, которые накладываются на запросы к базе данных. Однако роль с административными привилегиями (полные права) игнорирует любые шаблоны ограничений. Если вы включили пользователя в ограничивающую группу, но при этом оставили ему роль администратора, ограничения работать не будут. Это базовый принцип безопасности 1С: полные права всегда имеют приоритет над любыми запретами.

Производительный режим RLS и регламентные задания

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

Система анализирует настройки групп доступа и профилей.
Специальное регламентное задание Заполнение данных для ограничения доступа (или Обновление ключей доступа) рассчитывает так называемые "ключи доступа".
Результаты записываются в регистры сведений (например, Ключи доступа к объектам).

Если это задание не завершилось, зависло или отработало с ошибкой, пользователи не увидят изменений в правах. Выясним, какие ошибки могут возникнуть при выполнении этого задания. Часто в журналах регистрации можно встретить сообщение о невозможности обновить ключ объекта из-за того, что его тип не указан в определяемом типе ВладелецЗначенийКлючейДоступа.

Рассмотрим пример исправления такой ошибки, если в системе присутствуют доработанные или устаревшие объекты (например, документы с пометкой "не используется"):

Нужно перейти в конфигуратор и найти Определяемый тип ВладелецЗначенийКлючейДоступа. В его состав необходимо добавить тот тип объекта (документ или справочник), на котором спотыкается регламентное задание. После этого процесс расчета ключей сможет продвинуться дальше 100%.

Логика пересечения групп доступа: Принцип "ИЛИ"

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

Группа №1: Ограничивает доступ к контрагентам, разрешая только группу "Х".
Группа №2: Обычная группа (например, "Продажи"), в которой доступ к контрагентам вообще не ограничен (указано "Все разрешены").

В этом случае система применит логическое ИЛИ. Поскольку Группа №2 разрешает видеть всех контрагентов, ограничения Группы №1 будут полностью нивелированы. Чтобы RLS заработал, необходимо убедиться, что во всех группах доступа, назначенных пользователю, включено ограничение по нужному виду доступа (например, "Контрагенты"). Если хотя бы в одной группе этот вид доступа останется без фильтрации, пользователь увидит все записи.

Различия между Партнерами и Контрагентами

В конфигурации "Комплексная автоматизация 2.4" важно разделять сущности Партнеры и Контрагенты. Посмотрим на архитектуру системы: часто в интерфейсе пользователь видит список партнеров, а RLS настраивается для контрагентов. Если в настройках НСИ включено использование партнеров, то ограничивать доступ нужно именно по Группам доступа партнеров. Ограничение только справочника "Контрагенты" может не дать ожидаемого эффекта в управленческих отчетах и формах, работающих через партнеров.

Пошаговый алгоритм отладки RLS

Если вы все настроили, но видимость не изменилась, выполните следующие действия:

Проверьте регламентные операции: Перейдите в НСИ и администрирование — Обслуживание — Управление доступом. Проверьте, нет ли там сообщений о необходимости обновления данных. Нажмите кнопку "Обновить", если прогресс-бар не достиг 100%.
Проверьте отчет по правам: Зайдите в карточку "проблемного" контрагента под полными правами. В меню (обычно под кнопкой "Еще" или в отчетах) выберите пункт "Права доступа". Выберите пользователя, который не должен видеть этого контрагента. Система сформирует детальный отчет и покажет, какая именно роль или группа доступа дает разрешение на просмотр.
Очистите кэш и пересчитайте ключи: В критических случаях, когда данные явно противоречат настройкам, можно воспользоваться обработкой Управление доступом для полного перезаполнения данных доступа. Помните, что на больших базах это может занять длительное время.

Пример работы с кодом для проверки прав

Иногда программно нужно проверить, имеет ли пользователь право на конкретную запись с учетом RLS. Для этого в типовых решениях рекомендуется использовать метод ПараметрыСеанса.ДоступныеЗначенияКлючейДоступа (в контексте производительного RLS), но проще всего использовать запрос с ключевым словом РАЗРЕШЕННЫЕ.

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


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	Контрагенты.Ссылка КАК Ссылка,
    |	Контрагенты.Наименование КАК Наименование
    |ИЗ
    |	Справочник.Контрагенты КАК Контрагенты
    |ГДЕ
    |	Контрагенты.Ссылка = &Ссылка
    |РАЗРЕШЕННЫЕ";

Запрос.УстановитьПараметр("Ссылка", ПроверяемыйКонтрагент);
Результат = Запрос.Выполнить();

Если Результат.Пустой() Тогда
    Сообщить("Доступ к объекту ограничен правилами RLS");
КонецЕсли;

Именно использование слова РАЗРЕШЕННЫЕ в запросах динамических списков и отчетов заставляет систему применять настроенные нами ограничения. Если в вашем самописном отчете или форме списка это слово пропущено, RLS не сработает, даже если он настроен верно.

Подведем итог: Для работы RLS в КА 2.4 необходимо: убрать полные права у пользователя, дождаться завершения расчета ключей доступа без ошибок, убедиться в отсутствии "разрешающих" групп доступа и правильно выбрать разрез ограничения (Партнеры или Контрагенты).