Как проверить роль на клиенте 1С: способы, код и ошибки

Проверка роли на клиенте в 1С — частая задача при разработке управляемых форм: нужно скрыть кнопку, заблокировать поле или показать подсказку в зависимости от прав текущего пользователя. Проблема в том, что встроенный язык 1С жёстко разделяет клиентский и серверный контекст, и часть механизмов проверки прав доступна только на сервере.

Главная функция для проверки роли — РольДоступна(). Она встроена в глобальный контекст и, начиная с современных версий платформы 8.3, работает в том числе в клиентском коде, поскольку платформа кэширует роли пользователя при запуске сеанса. Однако у этого подхода есть ограничения, которые важно понимать, чтобы не строить логику безопасности на неустойчивом фундаменте.

Ниже разобраны рабочие способы проверки роли на клиенте: прямой вызов РольДоступна(), передача результата с сервера, использование параметров сеанса и функциональных опций, а также типичные ошибки, из-за которых проверка «молча» перестаёт работать.

Как работает функция РольДоступна на клиенте

Функция РольДоступна(ИмяРоли) возвращает Истина, если текущему пользователю назначена указанная роль (напрямую или через профиль группы доступа), и Ложь в противном случае. Имя роли передаётся строкой точно так, как оно задано в конфигураторе, с учётом регистра букв.

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

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

&НаКлиенте
Процедура ПриОткрытии(Отказ)
    Если РольДоступна("ПолныеПрава") Тогда
        Элементы.ГруппаАдминистрирование.Видимость = Истина;
    Иначе
        Элементы.ГруппаАдминистрирование.Видимость = Ложь;
    КонецЕсли;
КонецПроцедуры

Когда проверку нужно выполнять на сервере

Клиентская проверка роли подходит только для управления интерфейсом: видимость элементов, доступность кнопок, внешний вид формы. Любую логику, влияющую на данные — запись, проведение, доступ к документам — нужно защищать на сервере, потому что клиентский код пользователь при наличии навыков может обойти или подменить.

Правильный шаблон: на клиенте вы скрываете кнопку для удобства, а на сервере в обработчике записи повторяете проверку прав. Тогда даже если кто-то «включит» скрытую кнопку, серверный код откажет в выполнении операции.

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

Способ 1: прямой вызов РольДоступна в клиентском коде

Самый простой вариант — вызвать функцию непосредственно в клиентской процедуре. Это работает в модулях форм с директивой &НаКлиенте, в общих клиентских модулях и в модуле управляемого приложения.

&НаКлиенте
Процедура УстановитьДоступностьКнопок()
ЭтоМенеджер = РольДоступна("МенеджерПоПродажам");
ЭтоАдмин    = РольДоступна("ПолныеПрава");
Элементы.КнопкаСкидка.Доступность = ЭтоМенеджер Или ЭтоАдмин;
КонецПроцедуры

Если роль называется иначе, чем вы ожидаете, функция вернёт Ложь без ошибки — это частая причина «неработающей» проверки. Откройте конфигуратор и сверьте имя роли посимвольно, включая регистр и отсутствие пробелов.

Учтите, что в типовых конфигурациях права часто назначаются через профили групп доступа, а не напрямую. Функция РольДоступна() корректно учитывает роли, полученные через профиль, поэтому дополнительной логики не требуется.

Способ 2: вычислить на сервере и передать на клиент

Если в вашей версии платформы или в конкретном контексте клиентский вызов недоступен, используйте серверную функцию. В модуле формы создайте метод с директивой &НаСервере и вызывайте его из клиентского кода при открытии формы.

&НаСервере
Функция ЕстьПравоНаСкидку()
Возврат РольДоступна("МенеджерПоПродажам")
Или РольДоступна("ПолныеПрава");
КонецФункции

&НаКлиенте
Процедура ПриОткрытии(Отказ)
Элементы.КнопкаСкидка.Доступность = ЕстьПравоНаСкидку();
КонецПроцедуры

Такой вызов — это серверный вызов формы, он увеличивает нагрузку на соединение. Для одного обращения при открытии формы это приемлемо, но не вызывайте серверные функции в циклах или в обработчиках ожидания с маленьким интервалом.

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

1. 1
   Определите, какие роли участвуют в логике, и сверьте их имена в конфигураторе
2. 2
   Решите, нужна клиентская проверка (интерфейс) или серверная (данные)
3. 3
   Для интерфейса используйте РольДоступна() в клиентском коде
4. 4
   Для данных добавьте серверную проверку в обработчик записи или проведения
5. 5
   Перезапустите сеанс и проверьте поведение под пользователями с разными ролями

Способ 3: параметры сеанса и функциональные опции

Для решений, где проверка роли нужна во многих местах, удобнее один раз вычислить признак при старте сеанса и сохранить его в параметре сеанса. В модуле сеанса в обработчике УстановкаПараметровСеанса устанавливается значение, а дальше оно доступно и на клиенте, и на сервере без повторных вычислений.

// Модуль сеанса
Процедура УстановкаПараметровСеанса(ИменаПараметров)
ПараметрыСеанса.ЭтоМенеджерПоПродажам =
РольДоступна("МенеджерПоПродажам");
КонецПроцедуры

Альтернатива — функциональные опции, если видимость элементов должна зависеть не от конкретного пользователя, а от настроек учёта (например, «ведётся оптовая торговля»). Функциональные опции управляют видимостью элементов формы декларативно, без кода, и это предпочтительный способ для типовой логики интерфейса.

Как проверить, что роль назначена пользователю

Прежде чем отлаживать код, убедитесь, что роль действительно назначена. В конфигураторе откройте список пользователей (Администрирование → Пользователи), найдите нужного и на вкладке «Прочие» проверьте отмеченные роли. В типовых конфигурациях вместо этого откройте профиль группы доступа пользователя и посмотрите состав ролей профиля.

Быстрый способ проверки из кода — вывести результат функции в сообщение или в заголовок формы под тестовым пользователем:

&НаКлиенте
Процедура КомандаПроверитьРоль(Команда)
Сообщить("Роль доступна: " + РольДоступна("МенеджерПоПродажам"));
КонецПроцедуры

Помните про кэш ролей: если вы только что назначили роль пользователю, его активный сеанс её не увидит. Закройте и заново запустите клиентское приложение под этим пользователем, иначе будете отлаживать несуществующую проблему.

Типичные ошибки при проверке ролей на клиенте

Самая частая ошибка — опечатка в имени роли. Функция не генерирует исключение для несуществующей роли, а просто возвращает Ложь, поэтому ошибка проявляется как «вечно скрытая кнопка». Всегда копируйте имя роли из конфигуратора, а не набирайте вручную.

Вторая ошибка — забыть про кэш ролей и тестировать в том же сеансе после изменения прав. Третья — полагаться на клиентскую проверку как на механизм безопасности: скрытая кнопка не равна запрещённой операции. Четвёртая — выполнять серверные вызовы проверки роли в цикле или при каждом изменении поля, что заметно замедляет форму.

Ещё одна тонкость касается внешних пользователей и пользователей без ролей вообще: для них любая проверка вернёт Ложь. Если логика построена как «если не менеджер, то показать всё», пользователь без ролей получит лишний доступ к интерфейсу. Стройте условия от запретительной ветки: по умолчанию — минимум возможностей, дополнительные — только при явном наличии роли.

FAQ