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