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