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