Под каким пользователем запускается фоновое задание в 1С

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

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

Ключевое правило простое: если при программном запуске задания пользователь указан явно — сеанс откроется под ним. Если не указан — сеанс откроется без пользователя, то есть с пустым значением ПользователиИнфобазы.ТекущийПользователь(), и тогда задание получает права, определённые для «неавторизованного» сеанса. Для регламентных заданий действует похожая схема, но с дополнительными настройками в конфигураторе.

Как платформа определяет пользователя фонового задания

При вызове метода ФоновыеЗадания.Выполнить() можно передать параметр ИмяПользователя — имя пользователя информационной базы, от имени которого будет создан сеанс. Это прямой и рекомендуемый способ задать владельца: платформа создаст сеанс, авторизует в нём указанного пользователя (без проверки пароля, поскольку запуск инициирован изнутри системы) и выполнит код с его правами.

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

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

Кто владелец регламентного задания

Регламентное задание — это расписание, которое платформа запускает автоматически. У него есть собственное свойство «Имя пользователя», доступное в конфигураторе на закладке «Прочее» свойств задания. Если поле заполнено, каждый запуск создаёт сеанс от имени этого пользователя. Если поле пустое — сеанс создаётся без пользователя.

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

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

Как посмотреть, под кем реально выполняется задание

Самый быстрый способ в клиент-серверном варианте — консоль кластера серверов 1С. Откройте список сеансов информационной базы: фоновые задания отображаются с типом сеанса «Фоновое задание», и в колонке «Пользователь» видно владельца. Пустая колонка означает сеанс без пользователя. Там же видно время начала и текущий вызов СУБД.

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

Программно владельца можно определить изнутри самого задания: ПользователиИнфобазы.ТекущийПользователь() вернёт пользователя сеанса, а ИмяПользователя() — его имя. Эту пару строк удобно временно вставить в начало обработчика с записью в журнал регистрации, чтобы зафиксировать фактического владельца в конкретном запуске.

// Внутри обработчика фонового задания
ТекПользователь = ПользователиИнфобазы.ТекущийПользователь();
ЗаписьЖурналаРегистрации("Диагностика", УровеньЖурналаРегистрации.Информация,,,
    "Задание выполняется под: " + ?(ТекПользователь = Неопределено, "<пустой пользователь>", ТекПользователь.Имя));

Как задать пользователя для запуска

Для регламентного задания пользователь задаётся в конфигураторе: свойства задания → поле «Имя пользователя». Изменение требует обновления конфигурации базы данных, поэтому в продуктивной среде его планируют на технологическое окно. В типовых конфигурациях часть заданий настраивается через интерфейс «Регламентные и фоновые задания» в разделе администрирования — там владельца иногда можно поменять без конфигуратора.

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

1. 1
   Создайте служебного пользователя ИБ с нужными ролями и запретом интерактивного входа
2. 2
   Откройте конфигуратор, найдите регламентное задание и укажите его в поле «Имя пользователя»
3. 3
   Обновите конфигурацию базы данных в технологическое окно
4. 4
   Дождитесь запуска по расписанию и проверьте сеанс в консоли кластера
5. 5
   Проверьте журнал регистрации: ошибок прав быть не должно, пользователь сеанса — служебный

Права, RLS и типичные проблемы

Ограничение доступа на уровне записей (RLS) применяется к фоновому заданию так же, как к интерактивному сеансу. Если задание работает под пользователем с RLS-отборами, оно увидит только разрешённые данные — например, обмен может выгрузить неполный набор объектов. Это частая причина «недоезда» данных в интеграциях: код исправен, но владелец сеанса видит меньше, чем нужно.

Обратная ситуация опаснее: задание под пользователем с полными правами выполняет действия, которые никто не контролирует. Если такой задание пишет данные, автором изменений в журнале и в реквизитах «Автор» будет служебный пользователь — аудит усложняется. Рекомендуемый баланс: отдельный служебный пользователь с ровно теми ролями, которые нужны заданию, плюс запрет интерактивного входа.

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

Файловый и клиент-серверный режимы: различия

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

В файловом варианте задания выполняет тот процесс, который их «подхватил»: либо клиентское приложение с включённым выполнением заданий, либо выделенный сеанс, запущенный с параметром /Execute или через планировщик ОС. Если такого процесса нет — регламентные задания просто не выполняются, и это путают с проблемой прав. Пользователь внутри задания при этом по-прежнему берётся из свойств задания, а не из пользователя процесса-исполнителя.

FAQ