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