Как проверить пользователя в процедуре ПередНачаломРаботыСистемы и настроить режим РМК

Программист 1С v8.3 (Управляемые формы) 1С:Розница Управленческий учет Торговля и дистрибуция
← На главную

При разработке и настройке конфигураций на платформе 1С:Предприятие 8.3 часто возникает задача жесткого ограничения интерфейса для определенных категорий сотрудников. Типичный пример — работа кассира в конфигурации 1С:Розница 2.3. Несмотря на наличие типовых настроек, в новых версиях интерфейс РМК (Рабочее место кассира) может оставлять доступной боковую панель разделов, что нежелательно для безопасности и удобства работы. В этой статье мы разберем, как программно определить пользователя в момент запуска системы и принудительно установить режим основного окна «Рабочее место».

Проблема: ограничение доступа к меню подсистем

Рассмотрим ситуацию: в информационной базе работают Администратор и Кассир. Для Кассира необходимо, чтобы при входе сразу открывалось РМК, а любые меню (Продажи, Закупки, Настройки) были полностью скрыты. В типовой «Рознице» установка флагов «Открывать РМК при входе» не всегда блокирует навигацию по основной форме. Для решения этой задачи мы воспользуемся методом УстановитьРежимОсновногоОкна объекта КлиентскоеПриложение.

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

Способ 1. Использование функции ИмяПользователя()

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


&После("ПередНачаломРаботыСистемы")
Процедура Расш1_ПередНачаломРаботыСистемы(Отказ)    
    // Проверяем имя пользователя напрямую
    Если ИмяПользователя() <> "Администратор" Тогда
        // Устанавливаем режим, скрывающий все панели разделов и меню
        КлиентскоеПриложение.УстановитьРежимОсновногоОкна(РежимОсновногоОкнаКлиентскогоПриложения.РабочееМесто);
    КонецЕсли;        
КонецПроцедуры

Преимущество этого метода: он работает мгновенно без обращения к серверу, что важно для скорости запуска. Однако стоит учитывать риск: если администратор решит переименовать пользователя в «Админ» или «Вася», условие перестанет работать.

Способ 2. Проверка прав через РольДоступна()

Чтобы избежать привязки к конкретным именам, правильнее использовать проверку ролей. Функция РольДоступна также работает на клиенте и позволяет гибко управлять логикой запуска для групп пользователей. Разберем, как это реализовать:


&После("ПередНачаломРаботыСистемы")
Процедура Расш1_ПередНачаломРаботыСистемы(Отказ)    
    // Проверяем наличие роли Кассира (имя роли берем из конфигуратора)
    Если РольДоступна("ДобавлениеИзменениеЧековККМ") И НЕ РольДоступна("ПолныеПрава") Тогда
        КлиентскоеПриложение.УстановитьРежимОсновногоОкна(РежимОсновногоОкнаКлиентскогоПриложения.РабочееМесто);
    КонецЕсли;        
КонецПроцедуры

Этот подход считается более профессиональным, так как он ориентирован на полномочия, а не на строковые данные профиля.

Способ 3. Получение данных через ПараметрыСеанса (БСП)

В современных конфигурациях на базе БСП (Библиотека стандартных подсистем), таких как Розница 2.3 или УТ 11, информация о текущем пользователе часто хранится в параметрах сеанса. Доступ к ним напрямую из клиента в момент начала работы системы может быть ограничен, так как они инициализируются «лениво» (в момент первого обращения).

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

  1. Создадим в расширении серверный модуль (например, Расш1_СерверныйВызов) с флагом Вызов сервера.
  2. Напишем функцию, возвращающую статус пользователя.

// В серверном модуле расширения
Функция ТекущийПользовательЭтоКассир() Экспорт
    // Обращаемся к параметру сеанса
    Возврат ПараметрыСеанса.ТекущийПользователь.Наименование = "Кассир"; 
КонецФункции

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

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

Особенности режима «Рабочее место»

Метод УстановитьРежимОсновногоОкна с параметром РежимОсновногоОкнаКлиентскогоПриложения.РабочееМесто полностью меняет поведение программы:

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

Резюме

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

← На главную