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