Работа с конфигурациями 1С часто требует жесткого контроля над тем, какие данные пользователь может изменять, а какие должен видеть только для ознакомления. Ограничение доступа к конкретным элементам формы — это базовая задача при разработке интерфейсов, которая влияет на целостность базы данных и логику бизнес-процессов. Неправильная настройка свойств может привести к тому, что критически важные реквизиты будут изменены по ошибке или, наоборот, пользователь не сможет завершить операцию из-за заблокированного поля.
Существует несколько уровней управления доступом: от простого выставления галочки в конфигураторе до сложной программной логики, зависящей от прав пользователя или состояния документа. Понимание разницы между свойством ТолькоПросмотр и программным методом Доступность является ключевым для создания удобных и безопасных форм. В этой статье мы разберем все доступные инструменты платформы 1С для решения этой задачи, от визуальных настроек до написания кода.
Базовые свойства элемента формы в Конфигураторе
Самый простой и очевидный способ запретить изменение данных — это использование встроенных свойств элемента формы на этапе разработки конфигурации. В дереве элементов формы найдите нужный реквизит и перейдите на вкладку Свойства. Здесь вас интересует параметр ТолькоПросмотр. Если установить для него значение Истина, поле на клиенте станет серым, и курсор ввода в него установить будет невозможно.
Однако стоит помнить, что это статическое ограничение. Оно действует всегда, независимо от того, кто зашел в систему или в каком режиме открыт документ. Это идеально подходит для служебных полей, технических идентификаторов или расчетных величин, которые формируются автоматически и не должны правиться вручную. Например, поле Ссылка или ИдентификаторОбъекта часто делают недоступным по умолчанию.
Если вам нужно, чтобы поле было доступно для редактирования только при создании нового объекта, а при проведении становилось недоступным, одного свойства конфигуратора будет недостаточно. В таких случаях свойство ТолькоПросмотр оставляют ложным, а управление доступом перекладывают на программный код или динамические настройки. Также важно не путать это свойство с параметром Видимость, который полностью скрывает элемент с экрана, делая его недоступным для восприятия, а не только для редактирования.
Используйте свойство "ТолькоПросмотр" в конфигураторе только для полей, которые НИКОГДА не должны редактироваться пользователем ни при каких условиях. Для динамических сценариев используйте код.
Программное управление доступностью в модуле формы
Для реализации гибкой логики, когда доступность поля зависит от действий пользователя или значений других реквизитов, необходимо использовать программный код. В модуле формы существует коллекция Элементы, которая позволяет управлять свойствами элементов интерфейса в runtime. Основной метод для этого — Доступность. Присвоение этому свойству значения Ложь визуально блокирует поле, аналогично свойству в конфигураторе, но делает это динамически.
Часто возникает ситуация, когда нужно заблокировать поле сразу после открытия формы или при изменении конкретного переключателя. Для этого код размещают в обработчиках событий, таких как ПриОткрытии или ПриИзменении. Важно понимать, что изменение доступности элемента на клиенте не защищает данные на уровне базы данных, если у пользователя есть прямые права на запись в таблицу через другие интерфейсы или обработки.
&НаКлиенте
Процедура ПриОткрытии(Отказ)
// Блокируем поле суммы, если документ уже проведен
Если Объект.Проведен Тогда
Элементы.СуммаДокумента.Доступность = Ложь;
Элементы.Комментарий.ТолькоПросмотр = Истина;
КонецЕсли;
КонецПроцедуры
Обратите внимание на разницу между свойствами Доступность и ТолькоПросмотр в коде. Свойство Доступность управляет возможностью взаимодействия с элементом (ввод, клик, выбор из списка), в то время как ТолькоПросмотр влияет именно на возможность редактирования текста или значения, оставляя элемент активным (например, по нему можно пройти табом, скопировать значение). В большинстве случаев для полной блокировки используют именно Доступность = Ложь.
☑️ Алгоритм блокировки поля в коде
Использование условного оформления для визуального запрета
Условное оформление — это мощный инструмент платформы 1С, который позволяет менять внешний вид элементов в зависимости от условий без написания сложного кода в модуле формы. Хотя его прямое назначение — изменение цвета и шрифта, с его помощью можно эффективно сигнализировать пользователю о том, что поле не должно редактироваться, или даже блокировать ввод через специальные настройки.
В конструкторе условного оформления вы можете создать новое оформление, выбрать нужный элемент формы и установить условие срабатывания. Например, если значение поля Статус равно "Закрыто", можно сделать фон поля серым, а шрифт бледным. Это не запрещает ввод технически, но создает сильный визуальный барьер. Для реальной блокировки через оформление требуется использование специальных функций или комбинация с другими методами.
Особенно полезно условное оформление в табличных частях документов. Выделить конкретную строку или ячейку, которая не подлежит изменению, гораздо проще через оформление, чем прописывать циклы в коде для каждой строки таблицы. Это упрощает поддержку конфигурации и делает код чище. Однако помните, что условное оформление работает на стороне клиента и может быть обойдено опытными пользователями через внешние обработки, если не дублировать проверки на сервере.
⚠️ Внимание: Условное оформление влияет только на визуальное восприятие и клиентские ограничения. Оно не заменяет проверки прав доступа на уровне метаданных или серверных процедур записи данных.
Ограничение редактирования в отчетах и СКД
При работе с отчетами, построенными на системе компоновки данных (СКД), логика блокировки полей отличается от обычных форм документов. В отчетах пользователи часто имеют возможность настраивать выводимые поля, но иногда требуется зафиксировать определенные колонки, сделав их доступными только для чтения. Это реализуется через настройки схемы компоновки данных.
В свойствах поля набора данных или в настройках макета можно указать параметр, запрещающий редактирование. Если отчет предполагает ввод данных пользователем (параметры или поля ввода в самой таблице), то для запрета изменения конкретных ячеек используется свойство ТолькоПросмотр в параметрах макета. Это часто применяется в отчетах типа "Анализ данных", где часть колонок — это справочная информация, а часть — плановые значения, которые можно корректировать.
| Объект 1С | Метод блокировки | Уровень защиты | Гибкость настройки |
|---|---|---|---|
| Форма документа | Свойство элемента | Низкий (клиентский) | Отсутствует (статично) |
| Модуль формы | Код (Доступность) | Средний (клиентский) | Высокая (любые условия) |
| СКД (Отчеты) | Параметры макета | Средний | Средняя (настройки отчета) |
| Права доступа | РЛС (Роли) | Высокий (серверный) | Низкая (глобально) |
Важно отметить, что в СКД также можно использовать параметры, передаваемые из внешней обработки, которые могут динамически включать или выключать возможность редактирования полей. Это позволяет создавать универсальные отчеты-ввод данных, где администратор может разрешить заполнение определенных показателей только в определенные периоды времени.
Секрет динамических отчетов
В СКД можно использовать параметр "РежимРедактирования" типа Булево. Если передать в него Истина, макет отчета разрешит ввод в поля, если Ложь — все поля станут доступными только для чтения без изменения кода отчета.
Разграничение прав через роли и РЛС
Наиболее надежный способ сделать поле недоступным для редактирования — это использование механизма прав доступа (РЛС). Если пользователь не имеет права на запись конкретного объекта метаданных или его реквизита, никакие ухищрения в интерфейсе не позволят ему сохранить изменения. Это серверная защита, которую невозможно обойти через клиентский интерфейс.
В конфигураторе в разделе Права доступа можно детально настроить профили групп доступа. Вы можете создать роль, у которой будет право Изменение на документ в целом, но будет отсутствовать право на изменение конкретного реквизита. Однако стандартными средствами 1С запретить редактирование конкретного поля через РЛС для всех пользователей сложно, обычно это решается на уровне объектов.
Чаще всего используется подход, при котором создаются разные роли для разных отделов. Например, роль МенеджерПоПродажам имеет полные права на документ "ЗаказКлиента", а роль Бухгалтер имеет право только на чтение реквизита СуммаНДС. При попытке записать документ с изменением этого поля пользователем с ролью Бухгалтера система выдаст ошибку доступа, и транзакция будет отклонена сервером.
⚠️ Внимание: Интерфейсы и настройки прав могут отличаться в разных версиях платформы 1С (8.2, 8.3, 8.3.20+). Всегда проверяйте актуальность настроек в документации к вашей конкретной версии платформы перед массовым изменением ролей.
Частые ошибки и рекомендации по оптимизации
При реализации блокировки полей разработчики часто совершают ошибку, пытаясь защитить данные только визуально. Пользователь может скопировать значение из заблокированного поля, вставить его во внешнюю обработку и изменить в базе напрямую, если у него есть общие права на запись. Поэтому визуальная блокировка всегда должна подкрепляться проверками в модуле объекта.
В модуле документа, в обработчиках ПередЗаписью или ОбработкаПроведения, необходимо сравнивать текущие значения защищаемых реквизитов с их исходными значениями (например, из базы данных). Если значение изменилось, а у пользователя нет на это прав, следует вызвать Сообщить и отказать в записи. Это гарантирует целостность данных независимо от того, каким способом пользователь пытается их изменить.
Также стоит избегать излишней блокировки интерфейса. Если пользователь не понимает, почему поле серое и неактивное, это вызывает раздражение. Хорошим тоном считается добавление всплывающей подсказки к заблокированному полю, в которой кратко объясняется причина недоступности (например, "Поле заполняется автоматически после проведения").
Визуальная блокировка (Доступность=Ложь) — это удобство интерфейса, а не защита данных. Настоящую защиту обеспечивает только проверка прав в модуле объекта и РЛС.
FAQ: Часто задаваемые вопросы
Как сделать поле доступным только для чтения, но чтобы по нему можно было ходить табом?
Для этого в коде формы нужно установить свойство Элементы.ИмяПоля.ТолькоПросмотр = Истина, но оставить Доступность = Истина. В этом случае поле будет активным, фокус будет на него вставать, но изменить значение вручную пользователь не сможет.
Почему поле остается активным, хотя я поставил галочку "ТолькоПросмотр" в конфигураторе?
Проверьте код модуля формы. Возможно, в событии ПриОткрытии или ПриСозданииНаСервере есть программная установка свойства Доступность = Истина, которая перезаписывает настройки конфигуратора. Код имеет приоритет над статическими свойствами.
Можно ли заблокировать целую табличную часть для редактирования?
Да, это делается аналогично блокировке обычного поля. Нужно обратиться к элементу формы, соответствующему таблице (обычно это поле типа ПолеТабличногоДокумента или просто Таблица), и установить для него Доступность = Ложь. Это заблокирует выделение строк и ввод ячеек.
Как скрыть кнопку записи, если некоторые поля не заполнены, вместо блокировки полей?
Для этого лучше использовать механизм Валидации. В модуле объекта в процедуре ПередЗаписью проверьте заполненность обязательных полей. Если они пустые, используйте Сообщить с параметром Поле = ИмяПоля и прервите запись. Кнопку можно скрыть через условное оформление или код, но валидация надежнее.