При тонкой настройке прав доступа на уровне записей (RLS) в типовых конфигурациях на базе «Библиотеки стандартных подсистем» (например, в «1С:ERP Управление предприятием», «1С:Комплексная автоматизация» или «1С:Управление торговлей») разработчики периодически сталкиваются с парадоксальным поведением запросов. Если в запросе к независимому регистру сведений мы выбираем только измерения, запрос отрабатывает штатно и возвращает строки. Однако стоит добавить в список выборки хотя бы один ресурс — и результат запроса становится абсолютно пустым, даже если у роли пользователя есть полные права на эти ресурсы. Разберем по шагам, почему возникает такое поведение платформы, как с этим связан перенос настроек через универсальную XML-выгрузку и как правильно устранить проблему.
Рассмотрим типовую ситуацию. Имеется независимый непериодический регистр сведений (например, РеестрДокументов), на чтение которого в типовой роли назначено ограничение RLS. Выполним под пользователем с ограниченными правами следующий запрос через консоль запросов:
ВЫБРАТЬ РАЗРЕШЕННЫЕ
РеестрДокументов.Организация,
РеестрДокументов.Подразделение,
РеестрДокументов.МестоХранения,
РеестрДокументов.Ссылка
ИЗ
РегистрСведений.РеестрДокументов КАК РеестрДокументов
В этом случае запрос успешно возвращает записи. Если пользователь не имеет прав на определенные ссылочные объекты (организации или документы), платформа выводит на экран надпись «Объект не найден», но сама строка регистра отображается. Однако если мы модифицируем запрос и добавим в выборку ресурс:
ВЫБРАТЬ РАЗРЕШЕННЫЕ
РеестрДокументов.Организация,
РеестрДокументов.Подразделение,
РеестрДокументов.МестоХранения,
РеестрДокументов.Ссылка,
РеестрДокументов.СтатусОбработки // Ресурс регистра
ИЗ
РегистрСведений.РеестрДокументов КАК РеестрДокументов
Результат становится совершенно пустым. Выясним внутреннюю причину такого поведения платформы «1С:Предприятие».
Дело заключается в механизме поколоночного RLS и секции <Прочие поля> в настройках ролей. В платформе «1С:Предприятие» условия ограничения чтения могут накладываться как на конкретные поля метаданных, так и на группу <Прочие поля>. По умолчанию все ресурсы и реквизиты регистров сведений относятся к категории прочих полей, в то время как на измерения правила могут определяться отдельно или вовсе отсутствовать.
Когда в секции ВЫБРАТЬ присутствуют только измерения, на которые не наложено явное условие, платформа не внедряет жесткий фильтр RLS в итоговый SQL-запрос к СУБД. В результате записи физически читаются, а недостающие ссылочные данные заменяются представлением «Объект не найден». Но как только в запросе появляется хотя бы одно поле из категории <Прочие поля> (наш ресурс), платформа динамически активирует полное условие ограничения на уровне строк. Если условие не выполняется или дает результат ЛОЖЬ, отсекается вся строка целиком, и разработчик видит пустую выборку.
Проанализируем ситуацию, когда права настроены корректно, но RLS все равно отсекает все записи при обращении к ресурсам. Распространенной причиной является перенос профилей и групп доступа между идентичными информационными базами с помощью обработки «Выгрузка и загрузка данных XML».
Механизм разграничения прав доступа в современных версиях «1С:ERP» опирается на сложную вспомогательную архитектуру подсистемы «Управление доступом» БСП. Ограничения доступа по шаблонам вычисляются не на лету из первичных справочников, а используют оптимизированные вспомогательные регистры сведений (такие как ЗначенияГруппДоступа, ТаблицыГруппДоступа, КлючиДоступа и кэш прав пользователей).
При прямой загрузке данных через XML происходят следующие сбои:
ПрофилиГруппДоступа и ГруппыДоступа) записываются напрямую, часто с отключенными подписками на события или в обход экранной бизнес-логики.Разберем варианты восстановления работоспособности RLS — от ручного исправления до штатной фоновой актуализации.
Если объем перенесенных данных невелик, самый быстрый способ — пересоздать профиль или группу доступа вручную непосредственно в целевой информационной базе. Также можно открыть перенесенную группу доступа в режиме «1С:Предприятие», внести любое незначительное изменение (например, временно изменить описание или перевыбрать состав участников) и нажать кнопку Записать и закрыть. Запись объекта через штатный интерфейс инициирует фоновое обновление прав доступа для участников этой группы.
Чтобы восстановить служебные регистры без ручного перебивания справочников, воспользуемся штатным программным API «Библиотеки стандартных подсистем». Откроем внешнюю обработку или консоль кода под пользователем с полными административными правами и выполним процедуру:
// Полное принудительное обновление служебных данных подсистемы доступа
УправлениеДоступомСлужебный.ОбновитьДанныеУправленияДоступом(Истина);
Параметр Истина запускает безусловное и полное обновление всех ключей доступа, таблиц прав и вспомогательных регистров. После выполнения этой процедуры служебные связи будут пересчитаны, и RLS начнет работать корректно.
Актуализировать служебные данные можно средствами администрирования:
1cv8.exe ENTERPRISE /IBConnectionString "..." /ЗапуститьОбновлениеИнформационнойБазы. Это принудительно запустит все процедуры постобработки данных БСП.Обновление доступа на уровне записей;Заполнение данных для ограничения доступа.Для предотвращения и локализации аналогичных ошибок рекомендуется использовать встроенные диагностические средства:
DBMSSQL (или соответствующего диалекта вашей СУБД) и SDBL с фильтром по тексту запроса к исследуемому регистру. В технологическом журнале можно увидеть итоговый SQL-запрос со всеми подставленными подзапросами RLS и сразу определить, на каком именно левом или внутреннем соединении со служебными таблицами отсекаются данные.