Как правильно проверить роль пользователя из клиентского кода в расширении 1С?

← На главную

При разработке на управляемых формах 1С мы часто сталкиваемся с необходимостью ограничить видимость или доступность элементов интерфейса в зависимости от прав текущего пользователя. Однако попытка прямой проверки прав на клиенте нередко приводит к ошибкам. Рассмотрим, как правильно организовать проверку функции РольДоступна, особенно в рамках использования расширений конфигурации.

Выясним причину ошибки

Основная проблема заключается в том, что функция РольДоступна является строго серверной. Она работает с контекстом сеанса, который существует только на сервере 1С. Когда мы пытаемся вызвать ее из модуля, помеченного директивой &НаКлиенте, платформа выдает ошибку: «Процедура или функция с указанным именем не определена». На стороне клиента просто нет доступа к системной информации о ролях пользователя.

Разделим логику на клиентскую и серверную

Для корректной работы приложения в 1С принято разделять логику на клиентскую (интерфейс) и серверную (бизнес-логика, работа с данными). В расширениях конфигурации это разделение становится критически важным для стабильной компиляции. Рассмотрим по шагам, как настроить общие модули:

Создайте два отдельных общих модуля: один для клиентских вызовов, другой — для серверных.
Для серверного модуля установите следующие флаги в конфигураторе: Сервер, Вызов сервера.
Клиентскому модулю достаточно флага Клиент.

Такая архитектура позволяет безопасно обращаться к серверным методам из любого места клиентского кода, не создавая конфликтов в профилях безопасности расширения.

Пример реализации проверки роли

Давайте посмотрим, как это выглядит на практике. В серверном модуле Мой_ОбщегоНазначенияСервер создадим функцию, которая будет выполнять проверку:


// В свойствах модуля установлены флаги: Сервер, Вызов сервера
Функция ПроверитьНаличиеРолиПятница() Экспорт
    Возврат РольДоступна("Пятничка");
КонецФункции

Теперь из любого клиентского модуля, например, модуля формы, мы можем вызвать этот метод. Благодаря тому, что модуль имеет флаг Вызов сервера, платформа сама обеспечит передачу управления на сервер:


// Код на клиенте
&НаКлиенте
Процедура ПриОткрытии()
    Если Мой_ОбщегоНазначенияСервер.ПроверитьНаличиеРолиПятница() Тогда
        Элементы.КнопкаВыполнения.Видимость = Истина;
    КонецЕсли;
КонецПроцедуры

Особенности работы в расширениях

При работе в расширениях важно помнить о следующих нюансах:

Изоляция: Избегайте использования одного модуля с одновременно включенными флагами Клиент и Сервер. Это часто приводит к проблемам при сборке расширения.
Видимость объектов: Убедитесь, что общий модуль добавлен в расширение. Если вы не включите его в состав расширения, основной код конфигурации «не увидит» ваш новый экспортный метод.
Производительность: Помните, что каждый вызов серверной функции — это сетевой запрос. Если вам нужно проверить роль многократно (например, в цикле или при открытии сложной таблицы), лучше один раз выполнить проверку при инициализации формы и сохранить результат в переменную модуля:


&НаКлиенте
Перем ДоступРазрешен;

&НаКлиенте
Процедура ПриОткрытии()
    ДоступРазрешен = Мой_ОбщегоНазначенияСервер.ПроверитьНаличиеРолиПятница();
    // Дальше используем локальную переменную
КонецПроцедуры

Резюме

Мы проанализировали ситуацию и выяснили, что для проверки прав пользователя необходимо выносить логику в серверный общий модуль с установленным флагом Вызов сервера. Разделение клиентских и серверных модулей не только избавляет от ошибок компиляции в расширениях, но и соответствует стандартам разработки 1С (БСП). Используя данный подход, вы сможете безопасно и эффективно управлять интерфейсом программы в зависимости от прав текущего пользователя.