В процессе разработки и сопровождения конфигураций 1С одной из наиболее частых задач является разграничение прав доступа. Часто недостаточно просто запретить чтение или запись объекта — необходимо адаптировать интерфейс под конкретного пользователя, скрывая лишние кнопки, поля или целые вкладки. В этой статье мы подробно разберем, как управлять видимостью элементов на Управляемых формах (УФ) и Обычных формах (ОФ), а также проанализируем, какие права в конфигураторе могут представлять угрозу для целостности ваших данных.
Работа с интерфейсом в управляемом приложении существенно отличается от старых подходов. Здесь платформа берет на себя значительную часть работы по отрисовке, но мы можем гибко управлять этим процессом. Рассмотрим три основных способа.
1. Настройка пользовательской видимости в конфигураторе
Это самый простой и рекомендуемый способ, не требующий написания кода. Разберем его по шагам:
Этот метод хорош тем, что платформа сама оптимизирует передачу данных: если пользователю не положено видеть поле, оно даже не будет передано на клиент.
2. Использование функциональных опций
Проанализируем ситуацию, когда видимость элемента зависит не просто от роли, а от настроек системы. Функциональные опции позволяют привязать видимость элементов формы к значению константы или ресурса регистра. Если право доступа логически связано с какой-то опцией бизнеса, лучше использовать именно этот механизм.
3. Программное управление на сервере
Иногда логика скрытия слишком сложна для простых галочек. В этом случае мы используем процедуру ПриСозданииНаСервере. Рассмотрим пример кода, который скрывает элемент, если у пользователя нет полных прав:
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Проверяем наличие роли у текущего пользователя
Если Не РольДоступна("ПолныеПрава") Тогда
// Скрываем элемент управления
ЭлементФормы = Элементы.ГруппаСлужебнаяИнформация;
ЭлементФормы.Видимость = Ложь;
// Для максимальной безопасности можно полностью удалить элемент из коллекции
// Элементы.Удалить(Элементы.СпецПоле);
КонецЕсли;
КонецПроцедуры
Важный нюанс: использование удаления элемента через Элементы.Удалить() на сервере гарантирует, что пользователь не сможет включить видимость элемента через консоль отладки или технические средства на стороне клиента.
В обычных формах (толстый клиент) механизмы более прямолинейны, но требуют больше ручного труда. Основной инструмент здесь — программная проверка в событии открытия формы.
Рассмотрим вариант с созданием универсальной процедуры в общем модуле, чтобы не дублировать код в каждой форме. Создадим общий модуль РаботаСИнтерфейсом с установленным флагом Сервер и Вызов сервера.
// Процедура в общем модуле
Процедура НастроитьВидимостьПоРолям(Форма) Экспорт
Если Не РольДоступна("ПолныеПрава") Тогда
// Скрываем конкретные элементы по именам, если они есть на форме
Попытка
Форма.ЭлементыФормы.КнопкаУдалить.Видимость = Ложь;
Форма.ЭлементыФормы.СпецЦена.Доступность = Ложь;
Исключение
// Элемента может не быть на данной конкретной форме
КонецПопытки;
КонецЕсли;
КонецПроцедуры
Теперь в каждой форме, где нужна проверка, мы просто вызываем эту процедуру в событии ПриОткрытии:
Процедура ПриОткрытии()
РаботаСИнтерфейсом.НастроитьВидимостьПоРолям(ЭтаФорма);
КонецПроцедуры
Обратите внимание, что в ОФ мы часто используем свойство Доступность вместо Видимость. Это позволяет избежать "прыгающего" интерфейса, когда элементы исчезают и верстка формы сдвигается.
Выясним причину, по которой простого скрытия кнопок недостаточно. Безопасность данных строится на уровне Ролей в конфигураторе. Существует ряд прав, которые крайне опасно давать обычным пользователям.
1. Интерактивное удаление (Interactive Delete)
Это самое опасное право. Если оно включено, пользователь может физически удалить объект из базы нажатием клавиши Del, минуя проверку ссылочной целостности.
Последствия: в других документах, где была ссылка на этот объект, появится надпись <Объект не найден>. Это разрушает аналитику и может привести к критическим ошибкам в отчетах.
2. Интерактивная отмена проведения и изменение проведенных
Если пользователь может отменить проведение документа за прошлый год, это мгновенно изменит остатки на складах и взаиморасчеты в текущем периоде.
Рекомендация: всегда ограничивайте права на интерактивную отмену проведения для закрытых периодов через механизм Даты запрета редактирования или через RLS.
3. Вывод списка (Output)
Многие забывают про это право. Оно позволяет пользователю нажать "Еще" - "Вывести список" и сохранить любую таблицу (например, справочник всех клиентов с контактами или зарплатную ведомость) в файл Excel. Для защиты коммерческой тайны это право должно быть отключено у всех, кроме доверенных лиц.
4. Интерактивная пометка удаления
Хотя это безопаснее физического удаления, массовая пометка удаления важных справочников может парализовать работу компании. Разберем по шагам: лучше настроить бизнес-процесс так, чтобы помечать на удаление могли только ответственные сотрудники (администраторы НСИ).
Проанализируем, зачем нужны роли в 1С 8.3, помимо простого разрешения "Да/Нет":
Просмотр.Подводя итог, можно сказать, что грамотная настройка ролей — это фундамент безопасности. Скрытие элементов на форме — это лишь "косметический" слой интерфейса (UI/UX), который делает работу пользователя удобнее, в то время как реальная защита данных всегда должна настраиваться в объекте Роль внутри конфигуратора.