← На главную

При настройке ограничений доступа на уровне записей (RLS) в современных конфигурациях на базе «Библиотеки стандартных подсистем» (УТ 11, ERP 2, КА 2) специалисты часто сталкиваются с ситуацией: после включения ограничений по складам пользователь перестает видеть вообще все документы, даже если они соответствуют разрешенным складам. Проблема может казаться «глюком» системы, но на самом деле она связана со сложной архитектурой хранения прав доступа в БСП.

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

Причина 1: Несоответствие вспомогательных регистров и метаданных

В конфигурациях 1С 8.3 механизм RLS работает не только через SQL-запросы в ролях, но и опирается на вспомогательные таблицы (регистры сведений). Если вы переносили профили групп доступа из одной базы в другую или создавали новые роли, внутренние идентификаторы могли «рассинхронизироваться». Система ищет права для объекта с одним внутренним кодом (GUID), а в таблицах доступа записан другой.

Для исправления этой ситуации нам необходимо принудительно обновить данные справочников идентификаторов и регистров прав. Выполним следующие шаги:

1. Запустим обновление идентификаторов объектов метаданных. Это можно сделать программно или через консоль кода: Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанныеСправочника();
2. Обновим данные в регистре сведений ПраваРолей. Именно из него система берет информацию о том, какие роли имеют доступ к тем или иным объектам. Используем команду: РегистрыСведений.ПраваРолей.ОбновитьДанныеРегистра(Истина);
3. После выполнения этих действий обязательно нужно перезаписать профиль групп доступа или саму группу доступа, чтобы система пересчитала «Ключи доступа» для пользователей.

Причина 2: Жесткие требования к именованию ролей в БСП

Проанализируем архитектуру «Управления доступом». БСП ожидает, что роли, участвующие в ограничении прав, названы по определенному стандарту. Если вы создали свою роль, например, ДоступСкладыОграничение, алгоритмы системы могут просто проигнорировать её при заполнении вспомогательных таблиц.

Важный нюанс: для корректной работы RLS название новой роли должно начинаться с префикса:

• Чтение... (например, ЧтениеПеремещенийСУчетомСкладов)
• ДобавлениеИзменение... (например, ДобавлениеИзменениеДокументовЗакупки)

Если префикс отсутствует, роль может не попасть в регистр ТаблицыГруппДоступа, и система сформирует условие ГДЕ ЛОЖЬ в запросе, что и приведет к исчезновению всех документов из списка.

Причина 3: Использование роли OData как временное решение

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

Когда основная роль ограничивает доступ по складам, но при этом пользователю не хватает прав на какой-то технический реквизит, связанный справочник или внутренний параметр, используемый в шаблоне RLS, запрос аварийно скрывает данные. Роль OData «закрывает» эти пробелы в правах. Однако помните: это небезопасный костыль, так как он открывает доступ к данным через внешние интерфейсы. Мы рекомендуем использовать этот метод только для диагностики, чтобы убедиться, что проблема именно в недостатке прав на сопутствующие объекты.

Причина 4: Ошибки в регистре «Таблицы групп доступа»

Выясним причину, почему даже при правильных настройках профиля фильтрация не срабатывает. Часто проблема кроется в регистре сведений ТаблицыГруппДоступа. В нем должна быть четкая запись для каждой группы доступа пользователя с указанием типа документа (например, Перемещение товаров) и прав на чтение/изменение.

Посмотрим, как исправить записи в этом регистре:

1. Проверьте наличие роли в регистре ПраваРолей.
2. Если записи нет, выполните обновление регистра ПраваРолей, как было описано в первом решении.
3. Интерактивно (в пользовательском режиме) зайдите в Группу доступа, измените какое-нибудь поле (например, описание) и сохраните. Это инициирует процедуру ПриЗаписи, которая переформирует записи в ТаблицыГруппДоступа.

Причина 5: Режим «Производительный RLS» и ключи доступа

В версиях УТ 11.3 и 11.4 активно внедрялся механизм «Ключей доступа». В этом режиме система не вычисляет права при каждом открытии списка, а берет готовые разрешения из регистров группы «Ключи доступа». Если эти данные не актуальны, ограничения будут работать неверно.

Для решения этой проблемы проанализируем состояние регламентных заданий:

• Убедитесь, что задание Обновление прав доступа (оперативное) выполняется без ошибок.
• Проверьте, нет ли зависших записей в очереди обновления прав.
• В случае критического сбоя можно воспользоваться внешней обработкой Инструменты разработчика: Управление доступом (из дистрибутива БСП), которая позволяет запустить полное переформирование ключей доступа для конкретного пользователя.

Итоги и рекомендации

Если «каменный цветок» RLS не выходит, не спешите винить платформу. Скорее всего, нарушена целостность кэша прав в БСП. Алгоритм действий должен быть следующим:

1. Проверить префиксы в именах ролей (Чтение / ДобавлениеИзменение).
2. Принудительно обновить ИдентификаторыОбъектовМетаданных и ПраваРолей через программный код.
3. Перезаписать Группу доступа пользователя.
4. Очистить кэш на сервере 1С и локально у пользователя.
5. Убедиться, что включена функциональная опция Ограничивать доступ на уровне записей в настройках параметров системы.

Соблюдение этих методических рекомендаций позволит избежать использования сомнительных ролей-заплаток и настроить безопасную и производительную работу системы прав в УТ 11.