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