При разработке собственных документов в конфигурациях на базе БСП (таких как 1С:КА 2.4, ERP 2.5 или УТ 11) разработчики часто сталкиваются с ситуацией, когда механизм RLS (ограничение доступа на уровне записей) работает «наполовину». В списке документов пользователь продолжает видеть строки, которые должны быть скрыты, но вместо значений в защищенных полях отображается надпись «Объект не найден». Хотя для гибкого управления доступом и видимостью реквизитов существуют иные подходы, в этой статье мы рассмотрим, почему данная проблема возникает при использовании RLS и как ее исправить.
Для начала проанализируем ситуацию. Если в колонке «Партнер» или «Контрагент» вы видите «Объект не найден», это означает, что система успешно применила ограничение к ссылочному объекту (справочнику), но разрешила чтение самого Документа. В классическом RLS запрос модифицируется динамически, а в производительном режиме (упрощенном) система опирается на заранее рассчитанные Ключи доступа.
Выясним основную причину: механизм RLS в современных конфигурациях разделяет право на Чтение и право на Просмотр. Провести детальный анализ прав доступа к метаданным бывает полезно для понимания текущей конфигурации. Если ограничение наложено только на реквизит, но не на сам объект метаданных в целом, документ останется в списке, но его содержимое будет «битым» для пользователя. Чтобы строка скрылась полностью, ограничение должно запрещать чтение самой записи таблицы документа.
В режиме производительного RLS недостаточно просто добавить шаблон в роль. Система должна знать, по каким полям строить ключи доступа. Для этого нам необходимо прописать логику в модуле менеджера вашего самописного документа. Разберем по шагам, что нужно добавить.
Найдем в модуле менеджера процедуру ПриЗаполненииОграниченияДоступа. Если её нет — её необходимо создать. Именно здесь мы указываем подсистеме управления доступом, что наш документ нужно фильтровать, например, по партнеру.
Процедура ПриЗаполненииОграниченияДоступа(Ограничение) Экспорт
Ограничение.Текст =
"РазрешитьЧтениеИзменение
|ГДЕ
|ЗначениеВДопусках(РеквизитПартнер)";
КонецПроцедуры
В данном примере РеквизитПартнер — это имя реквизита вашего документа. Аналогичным образом можно настроить RLS по организации или любому другому ключевому разрезу. Использование конструкции ЗначениеВДопусках позволяет системе БСП автоматически связать права на документ с правами на партнера, которые уже настроены в профилях групп доступа.
Чтобы подсистема БСП «увидела» ваш новый документ, он должен быть включен в состав определенных метаданных. Проанализируем состав определяемого типа ВладелецОбъектаАдресногоХранилища и, что более критично для RLS, проверим наличие подписок на события, которые отвечают за обновление ключей доступа. Обычно это подписки типа ЗаписатьКлючиДоступа....
Если ваш документ не входит в состав объектов, для которых рассчитываются ключи доступа, то таблицы ограничений будут пустыми. На этом этапе полезно проверить, какие роли и профили в принципе имеют доступ к объекту. По умолчанию система может либо разрешить чтение всем, либо запретить его вовсе, выдавая те самые «Объект не найден» из-за частичного срабатывания прав на справочники.
Вернемся в конфигуратор и проверим настройки роли. Рассмотрим типичную ошибку: ограничение установлено на право Чтение, но в поле «Ограничение доступа» выбран только конкретный реквизит. Для правильной работы нужно сделать следующее:
#ПоЗначениям).Важно: если вы используете производительный RLS, шаблон в коде роли должен соответствовать синтаксису БСП. Обычно он выглядит так:
#ПоЗначениям("Документ.ИмяВашегоДокумента","Чтение","", "Партнеры","Партнер", "","","","","","","","")
После внесения изменений в код или метаданные, старые ключи доступа, хранящиеся в регистрах, становятся неактуальными. Рассмотрим, как заставить систему пересчитать права. В пользовательском интерфейсе выполним следующие действия:
Пока регламентное задание по обновлению ключей не завершится, данные в списках могут отображаться некорректно. Проверить состояние можно в регистре сведений КлючиДоступаКОбъектам.
Иногда проблема кроется в кэше параметров сеанса. В платформе 8.3.25 механизмы работы с временными таблицами в RLS были оптимизированы, что иногда конфликтует со старыми версиями БСП (например, 3.0.3). Если после всех настроек строки не скрываются, попробуйте очистить серверный кэш и перезапустить сеанс пользователя.
Также проверим, не включена ли у пользователя роль Полные права. При наличии полных прав механизмы RLS игнорируются платформой, и никакие ограничения не будут действовать. Если вы тестируете систему под администратором, вы никогда не увидите работу RLS в действии.
Подведем итог. Чтобы строки в списке скрывались полностью, а не превращались в «Объект не найден», мы должны обеспечить три условия:
ПриЗаполненииОграниченияДоступа, чтобы БСП знала, как строить связи ключей доступа.Соблюдение этих шагов гарантирует корректную работу производительного RLS и обеспечит безопасность данных в вашей системе 1С.