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