При разработке собственных конфигураций на базе Библиотеки стандартных подсистем (БСП) программисты часто сталкиваются с ситуацией, когда стандартные механизмы ограничения доступа на уровне записей (RLS) ведут себя непредсказуемо. Вы настраиваете роли, создаете профили групп доступа, прописываете шаблон #ПоЗначениям, но в итоге пользователь либо видит все записи, либо не видит ничего. Рассмотрим подробно, почему это происходит и как заставить механизмы БСП работать корректно.
Типичная ситуация: в справочнике Проекты необходимо ограничить видимость так, чтобы автор видел только свои записи. Вы используете стандартный шаблон БСП в тексте ограничения роли:
#ПоЗначениям( "Справочник.Проекты","Чтение","", "Пользователи","Автор", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","", "","" )
Несмотря на то, что в профиле групп доступа вид доступа "Пользователи" настроен правильно, список проектов остается пустым. Проблема здесь кроется не в синтаксисе шаблона, а в том, как БСП интерпретирует этот запрос. В отличие от простых условий ГДЕ Автор = &АвторизованныйПользователь, шаблон #ПоЗначениям — это сложная конструкция, которая при компиляции превращается в соединение со служебными таблицами (регистрами сведений), такими как КлючиДоступаКОбъектам или ТаблицыГруппДоступа. Если эти таблицы не заполнены или содержат устаревшие данные, система безопасности блокирует доступ ко всем записям по принципу "запрещено всё, что явно не разрешено".
Проанализируем техническую подоплеку. БСП хранит информацию о структуре конфигурации в справочнике ИдентификаторыОбъектовМетаданных. Если вы добавили новый справочник или изменили существующий, но справочник идентификаторов не обновился, механизмы RLS не смогут сопоставить объект метаданных с его внутренним кодом в системе прав. Это часто случается при ручной разработке или частичном переносе изменений между базами.
Для высокой производительности БСП использует кэширование прав. При каждом изменении настроек доступа или структуры конфигурации должны запускаться процедуры «после обновления». Если база была обновлена некорректно или версия конфигурации не была изменена в процессе разработки, БСП "считает", что обновлять данные не нужно. В итоге регистры, отвечающие за ключи доступа, остаются пустыми или содержат мусорные данные.
Выясним, как заставить систему пересчитать все вспомогательные данные без написания кода. Самый простой и эффективный способ — запуск информационной базы в режиме «Предприятие» со специальным ключом. Для этого выполните следующие действия:
/C ЗапуститьОбновлениеИнформационнойБазы (обратите внимание, что символ "C" должен быть латинским).Рассмотрим ситуацию, когда стандартный запуск не помогает. БСП ориентируется на номер версии конфигурации. Если вы ведете разработку и номер версии в конфигураторе не меняется, процедуры обновления игнорируются. Чтобы обмануть систему и вызвать обновление, можно временно изменить версию в коде или константах:
Найдите в конфигурации, где хранится текущая версия (обычно это функция ПриОпределенииОбщихПараметров в модуле ОбновлениеИнформационнойБазыПереопределяемый). Увеличьте номер версии, обновите конфигурацию базы данных и запустите "1С:Предприятие". Это инициирует полный цикл обработки данных подсистемы управления доступом.
Также можно воспользоваться программным методом сброса параметров сеанса и кэша прав:
ПараметрыРаботыПользователей.СоздатьМенеджерЗначения().ОбновитьОбщиеПараметры();
УправлениеДоступом.ОбновитьКлючиДоступа();
Если проблема только в идентификаторах объектов метаданных, воспользуемся встроенными средствами БСП для их актуализации. Разберем пример кода, который можно выполнить во внешней обработке под полными правами:
// Обновление идентификаторов метаданных
Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанныеСправочника();
// Запуск фонового задания по пересчету прав (если используется производительный RLS)
УправлениеДоступомСлужебный.ЗаполнитьДанныеДляОграниченияДоступа();
Посмотрим на ситуацию глазами системы. Чтобы понять, почему шаблон не работает, используйте консоль запросов, которая поддерживает запуск под другим пользователем с включенным RLS. Выполните простой запрос к справочнику Проекты под проблемным пользователем. Если в консоли вы увидите текст запроса, трансформированный системой, обратите внимание на секцию ГДЕ. Если вы видите там ГДЕ ЛОЖЬ или ГДЕ 1=0, это явный признак того, что система управления доступом не нашла разрешающих записей в регистрах КлючиДоступаКОбъектам.
Важный момент: Проверьте процедуру ПриЗаполненииВидовДоступа в модуле УправлениеДоступомПереопределяемый. Убедитесь, что вид доступа Пользователи там зарегистрирован и для него разрешено использование в ограничениях. Если вид доступа не описан программно, шаблон #ПоЗначениям просто проигнорирует соответствующие параметры профиля.
Если вам нужно быстро решить задачу и вы не планируете использовать сложные иерархические группы доступа, можно отказаться от шаблона #ПоЗначениям в пользу прямого условия. Это снизит нагрузку на базу данных и избавит от зависимости от вспомогательных таблиц БСП:
Проекты ГДЕ Проекты.Автор = &АвторизованныйПользователь
Однако помните, что такой подход идет вразрез с методологией БСП и лишает вас возможности гибко настраивать права через интерфейс (профили и группы доступа) без изменения кода ролей. Для "чистого" решения в стиле БСП всегда добивайтесь корректной работы шаблона через обновление вспомогательных данных.
Подведем итог. Если RLS в БСП не работает:
/C ЗапуститьОбновлениеИнформационнойБазы.