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