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