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