Почему после копирования типовой роли список документов становится пустым и как правильно настроить RLS в БСП

При разработке в современных конфигурациях на базе Библиотеки стандартных подсистем (БСП), таких как ERP, Управление торговлей или Комплексная автоматизация, программисты часто сталкиваются с ситуацией: при копировании типовой роли (например, ДобавлениеИзменениеЗаказовКлиентов) список документов у пользователя становится абсолютно пустым. Если же удалить текст ограничения доступа (RLS) из роли, документы появляются. Разберем подробно, почему это происходит, как устроена современная система разграничения прав и что нужно сделать, чтобы ваша новая роль заработала корректно.

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

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

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

Шаг 1. Обновление идентификаторов объектов метаданных

Первое, что мы должны сделать при создании любых новых объектов метаданных (включая роли) — это обновить справочник ИдентификаторыОбъектовМетаданных. БСП хранит в нем информацию о структуре конфигурации для управления правами. Рассмотрим, как это сделать программно или через интерфейс:

1. Запустите информационную базу с параметром командной строки /C ЗапуститьОбновлениеИнформационнойБазы. Это инициирует выполнение всех процедур обновления, включая регистрацию новых метаданных.
2. Если это не помогло, используйте внешнюю обработку ОбновлениеВспомогательныхДанных.epf, которая обычно входит в состав дистрибутива БСП (раздел «Инструменты разработчика»).

Шаг 2. Обновление вспомогательных данных и ключей доступа

После того как роль зарегистрирована в системе, нам нужно заставить БСП пересчитать таблицы прав. Посмотрим на методы, которые позволяют это сделать. Если мы работаем в консоли кода, можно программно инициировать обновление для конкретных объектов:

// Пример программного обновления прав для документов ЗаказКлиента
УправлениеДоступом.ОбновитьСпискиПравДоступа();

Этот метод пометит данные как требующие обновления, и фоновое задание постепенно пересчитает ключи доступа. Однако для новой роли этого может быть недостаточно. Важно убедиться, что в профиле групп доступа, где используется эта роль, правильно настроены Виды доступа (например, «Организации» или «Склады»).

Шаг 3. Корректное написание шаблонов RLS для универсального режима

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

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

Рассмотрим, что здесь происходит:

• Инструкция #Если &ОграничениеДоступаНаУровнеЗаписейУниверсально проверяет, включен ли в константах системы современный механизм RLS.
• Если включен, вызывается шаблон #ДляОбъекта(""). В этом случае реальное ограничение будет браться из заранее рассчитанных таблиц ключей доступа.
• Если режим универсального ограничения выключен, срабатывает классический метод #ПоЗначениям.

Шаг 4. Настройка Профиля групп доступа

Даже если роль скопирована идеально и данные обновлены, доступ может быть закрыт на уровне настроек пользователя. Проанализируем ситуацию в пользовательском режиме:

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

Шаг 5. Диагностика с помощью инструментов разработчика

Если список заказов по-прежнему пуст, воспользуемся Консолью анализа прав доступа. Этот инструмент позволяет увидеть «сырой» SQL-запрос, который платформа отправляет к СУБД. Выясним причину через анализ запроса:

Если в тексте запроса вы видите конструкцию типа ГДЕ 1=0 или соединение с пустой временной таблицей, это явный признак того, что для данной связки «Пользователь — Роль — Объект» не найдены записи в регистре КлючиДоступаКОбъектам. В этом случае необходимо повторно запустить процедуру обновления вспомогательных данных или проверить, назначены ли пользователю конкретные значения доступа (например, разрешена ли ему хотя бы одна организация).

Подведем итоги

Работа с RLS в современных конфигурациях 1С требует понимания того, что роль — это лишь часть сложного механизма. Для того чтобы копия типовой роли заработала, необходимо:

1. Зарегистрировать новую роль в Идентификаторах объектов метаданных.
2. Убедиться, что шаблон RLS поддерживает универсальный режим (#ДляОбъекта).
3. Обновить вспомогательные данные через ключ /C ЗапуститьОбновлениеИнформационнойБазы.
4. Настроить виды доступа в Профиле групп доступа.

Соблюдение этого алгоритма позволит избежать проблем с «исчезновением» данных и обеспечит корректную работу системы безопасности вашей конфигурации.