При работе со специализированными отраслевыми решениями, такими как «1С:Производственная безопасность», программисты часто сталкиваются с ошибками ограничения доступа, которые проявляются не в виде прямого сообщения «Нарушение прав доступа», а как техническая ошибка выполнения запроса «Поле не найдено». Особенно часто это происходит в сложных регламентированных отчетах, например, в «Сведениях о производственном контроле по приказу 518». В этой статье мы подробно разберем, почему возникает такая ошибка при обращении к реквизитам через точку и как правильно настроить права доступа в конфигурациях на базе БСП (Библиотеки стандартных подсистем).
Рассмотрим ситуацию: отчет прекрасно работает под пользователем с полными правами, но при попытке формирования под ролью «Руководитель подразделения» система выдает ошибку:
{(10, 38)}: Поле не найдено "ДоговорыСтрахованияОПО.Договор.ПометкаУдаления"
Проанализируем текст ошибки. Проблема возникает не в самом регистре сведений ДоговорыСтрахованияОПО, а при попытке получить данные из справочника, на который ссылается поле Договор. В системе 1С, если в запросе используется обращение «через точку» (например, Договор.ПометкаУдаления), платформа проверяет наличие прав доступа Чтение и Просмотр на каждый объект в цепочке. Если у пользователя есть права на регистр, но нет прав на справочник ДоговорыКонтрагентов или ДоговорыСтрахования, механизм RLS (Row Level Security) скрывает эти поля, и для построителя запроса они просто «перестают существовать».
Первое, что мы должны сделать при диагностике проблем с правами в отчетах — это убедиться, что запрос корректно обрабатывает ограничения доступа. Если отчет самописный или дорабатывается, в тексте запроса обязательно должна присутствовать инструкция РАЗРЕШЕННЫЕ. Это позволит системе не выдавать ошибку, а просто исключить из результата те записи, на которые у пользователя нет прав.
Посмотрим на пример того, как это должно выглядеть в коде:
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ РАЗРЕШЕННЫЕ
| Сведения.Договор КАК Договор,
| Сведения.Договор.ПометкаУдаления КАК ПометкаУдаления
|ИЗ
| РегистрСведений.пбДоговорыСтрахованияОПО КАК Сведения
|ГДЕ
| НЕ Сведения.Договор.ПометкаУдаления";
Однако стоит помнить, что использование РАЗРЕШЕННЫЕ — это лишь способ избежать аварийного завершения. Если поле ПометкаУдаления принципиально важно для логики отчета (например, для фильтрации), нам все равно придется предоставить пользователю права на объект-владелец.
В современных конфигурациях права часто назначаются не вручную в конфигураторе, а программно через механизмы БСП в общих модулях (например, пбУправлениеДоступом). Если мы добавляем новую роль или изменяем существующий профиль, необходимо убедиться, что в список ролей включены все необходимые объекты НСИ (нормативно-справочной информации).
Рассмотрим пример функции, которая формирует профиль для руководителя подразделения. Обратите внимание, как важно добавлять не только основные роли раздела, но и права на просмотр связанных справочников:
Функция ДобавитьПрофильРуководительПодразделения() Экспорт
ОписаниеПрофиля = УправлениеДоступом.НовоеОписаниеПрофиляГруппДоступа();
ОписаниеПрофиля.Идентификатор = "3ae89e04-3e70-4d41-84bf-e8b47bff3cfb";
ОписаниеПрофиля.Наименование = НСтр("ru = 'Руководитель подразделения'");
// Добавление базовых ролей (БСП и ПБ)
пбРаботаСРолями.ДополнитьПрофильОбязательнымиРолями(ОписаниеПрофиля);
пбРаботаСРолями.ДополнитьПрофильОбязательнымиРолямиПБ(ОписаниеПрофиля);
// Добавляем специфические роли для работы с отчетом
ОписаниеПрофиля.Роли.Добавить("прбИспользованиеОтчетаСведенияОПроизводственномКонтроле");
// ВАЖНО: Добавляем права на справочники, к которым отчет обращается через точку
ОписаниеПрофиля.Роли.Добавить("пбПросмотрСправочникаКонтрагенты");
// Если отчет обращается к договорам страхования:
ОписаниеПрофиля.Роли.Добавить("прбПросмотрДополненийДоговоров");
// Настройка ограничений по видам доступа
ОписаниеПрофиля.ВидыДоступа.Добавить("Организации");
ОписаниеПрофиля.ВидыДоступа.Добавить("Подразделения");
Возврат ОписаниеПрофиля;
КонецФункции
Выясним причину, почему даже после добавления ролей ошибка может сохраняться. В системах с БСП права кэшируются. Если вы просто изменили код в общем модуле, система может не «увидеть» обновленный состав ролей в режиме предприятия.
Это критически важный этап, о котором часто забывают разработчики. БСП хранит информацию об объектах метаданных и их связях с ролями в специальных справочниках и регистрах (например, Идентификаторы объектов метаданных). Чтобы изменения в программном коде профилей вступили в силу, необходимо запустить процедуру обновления информационной базы.
Для этого выполним следующие действия:
/c ЗапуститьОбновлениеИнформационнойБазы
Проанализируем ситуацию: данный ключ заставляет систему пересчитать права доступа, обновить вспомогательные таблицы RLS и актуализировать справочник идентификаторов. После выполнения этой команды ошибка «Поле не найдено» обычно исчезает, так как система начинает корректно сопоставлять права роли с полями метаданных.
Если проблема сохраняется, разберем еще несколько тонких моментов:
Договор имеет составной тип (например, СправочникСсылка.ДоговорыКонтрагентов и СправочникСсылка.ДоговорыСтрахования), убедитесь, что у пользователя есть права на ВСЕ типы, входящие в этот состав. В противном случае обращение через точку к общему реквизиту (например, ПометкаУдаления) может вызвать ошибку.ВЫРАЗИТЬ(Сведения.Договор КАК Справочник.ДоговорыСтрахования).ПометкаУдаления
Подведем итог: исправление ошибки требует комплексного подхода — от корректного написания запроса с использованием РАЗРЕШЕННЫЕ до тщательной настройки программных профилей доступа и обязательного обновления кэша метаданных БСП с помощью ключа /c ЗапуститьОбновлениеИнформационнойБазы. Соблюдение этой последовательности гарантирует стабильную работу сложных отчетов под любыми ролями пользователей.