Как настроить видимость и автоматическое заполнение полей на форме в зависимости от роли пользователя в 1С?

← На главную

При разработке конфигураций на платформе 1С:Предприятие часто возникает задача ограничить доступ к конкретному полю или автоматизировать его заполнение только для определенной категории сотрудников. Если в Управляемом интерфейсе для этого предусмотрены встроенные механизмы в палитре свойств, то в Обычном интерфейсе (толстый клиент) разработчику приходится комбинировать программные методы и настройку метаданных. Разберем подробно, как реализовать этот функционал на примере задачи: настроить автоматическое заполнение и доступность поля «Наименование» только для пользователей с ролью «Технолог».

Различие подходов в обычном и управляемом интерфейсах

Для начала проанализируем ситуацию: почему в обычном интерфейсе нельзя просто поставить «галочку»? В управляемых формах 1С 8.3 существует свойство элемента формы ПользовательскаяВидимость, где можно флажками отметить нужные роли. В обычном интерфейсе (версии 8.2 и режим толстого клиента 8.3) элементы формы не имеют прямой привязки к ролям через свойства. Здесь управление осуществляется либо на уровне прав доступа к объекту метаданных, либо через код в модуле формы.

Решение 1: Программное управление в модуле формы

Это самый гибкий и распространенный способ. Мы будем использовать встроенную функцию РольДоступна(), чтобы динамически менять свойства элементов формы при ее открытии. Рассмотрим по шагам, как это сделать.

Откроем модуль формы нужного нам объекта (например, справочника) и найдем процедуру ПриОткрытии() или ПередОткрытием(). Пропишем в ней следующую логику:


Процедура ПриОткрытии()
    // Проверяем, есть ли у текущего пользователя роль "Технолог"
    Если РольДоступна("Технолог") Тогда
        // Разрешаем редактирование поля
        ЭлементыФормы.Наименование.Доступность = Истина;
    Иначе
        // Для всех остальных пользователей запрещаем редактирование
        ЭлементыФормы.Наименование.Доступность = Ложь;
        // Можно также использовать ТолькоПросмотр, чтобы оставить возможность копирования текста
        // ЭлементыФормы.Наименование.ТолькоПросмотр = Истина;
    КонецЕсли;
КонецПроцедуры

Разберем, что именно мы сделали. Объект ЭлементыФормы дает нам доступ ко всем визуальным компонентам. Установив свойство Доступность в значение Ложь, мы делаем поле «серым» — пользователь видит данные, но не может их изменить или даже поставить туда курсор. Если ваша конфигурация построена на базе БСП (Библиотеки стандартных подсистем), рекомендуется использовать функции общего модуля, например Пользователи.РолиДоступны("Технолог"), так как это делает код более стабильным при переименовании ролей в будущем.

Решение 2: Ограничение прав на уровне метаданных

Если нам нужно не просто «спрятать» поле на одной форме, а жестко запретить его редактирование на уровне системы, мы обратимся к настройкам роли в Конфигураторе. Посмотрим на этот процесс подробнее:

Откройте дерево метаданных и перейдите в ветку Общие -> Роли.
Выберите нужную роль (например, «Менеджер», которому нельзя менять поле).
В правой части окна найдите объект (справочник или документ).
В списке прав найдите строку Чтение или Изменение.
В нижней части окна появится список всех реквизитов этого объекта. Здесь вы можете снять флажок в колонке Редактирование для конкретного поля (например, Наименование).

Важный нюанс: если вы снимете право «Редактирование» в метаданных, но оставите поле доступным на форме в коде, система выдаст ошибку «Нарушение прав доступа» только в момент попытки записи объекта. Поэтому правильной практикой считается совмещение обоих методов: программное отключение Доступность = Ложь на форме для удобства пользователя и ограничение прав в метаданных для безопасности.

Решение 3: Реализация автозаполнения по условию

Теперь выясним, как реализовать автозаполнение поля «Наименование» специально для технологов. Эту логику лучше всего разместить в Модуле объекта, чтобы она срабатывала независимо от того, из какой формы (или даже программно) записывается объект.

Проанализируем пример кода в процедуре ПередЗаписью:


Процедура ПередЗаписью(Отказ)
    // Проверяем роль и условие, что это новый объект или поле еще не заполнено
    Если РольДоступна("Технолог") Тогда
        // Вызываем функцию формирования имени на основе других реквизитов
        Наименование = СформироватьНаименованиеПоСтандарту();
    КонецЕсли;
КонецПроцедуры

Чтобы пользователь видел результат автозаполнения сразу на экране, а не только после нажатия кнопки «Записать», мы можем добавить аналогичный вызов в модуле формы. Например, в событии ПриИзменении тех полей, от которых зависит наименование (артикул, цвет, размер и т.д.).

Риски и «532 стандарт» (Независимые права подчиненных объектов)

Разберем важный момент, касающийся безопасности и архитектуры прав, упомянутый опытными разработчиками. При работе с ролями в 1С существует настройка «Независимые права подчиненных объектов».

Если этот флаг включен, права на реквизиты и табличные части перестают наследоваться от прав на весь справочник. Это позволяет тонко настраивать доступ, но таит в себе опасность. Выясним причину: если при создании новой роли оставить включенным параметр «Устанавливать права по умолчанию», то при добавлении в конфигурацию любых новых полей эта роль автоматически получит к ним доступ. В больших системах это может привести к тому, что пользователи увидят конфиденциальные данные, которые вы планировали скрыть. Поэтому всегда проверяйте состав прав при добавлении новых реквизитов в объект.

Резюме: для решения задачи автора в обычном интерфейсе мы рекомендуем использовать проверку РольДоступна() в процедуре ПриОткрытии для визуального управления доступом и проверку в ПередЗаписью для реализации логики автоматического формирования данных.