От какого пользователя запускается регламентное задание в 1С

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

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

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

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

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

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

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

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

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

Третий способ — программный. Внутри обработчика задания можно временно добавить запись в журнал:

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

Контрольные точки

Как проверить результат

Колонка «Пользователь» в списке фоновых заданий

Норма

Указан ожидаемый служебный пользователь

Тревожный признак

Пусто или указан случайный пользователь

Журнал регистрации по событию задания

Норма

События от имени назначенного пользователя, без ошибок доступа

Тревожный признак

Ошибки «Нарушение прав доступа» или другой пользователь

Свойство «Пользователь» регламентного задания

Норма

Заполнено явно

Тревожный признак

Пустое — поведение зависит от умолчаний

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

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

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

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

Какие права нужны служебному пользователю

Принцип — минимально достаточные права. Если задание только формирует и рассылает отчёт, пользователю не нужны права на изменение документов. Если задание выполняет обмен данными, ему нужны права на чтение и запись участвующих объектов, а также на использование планов обмена.

Частая ловушка — роли, проверяющие текущего пользователя в коде. Некоторые типовые механизмы (например, подсистема «Пользователи» в БСП) ожидают, что пользователь сопоставлен с элементом справочника «Пользователи». Если служебный пользователь не добавлен в этот справочник, задание может падать с ошибками вроде «Пользователь не найден» даже при наличии прав. Добавьте служебного пользователя в справочник «Пользователи» и при необходимости включите его в нужные группы доступа.

Особенности файлового, клиент-серверного режима и сервиса

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

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

В сервисе 1С:Фреш и подобных облачных режимах регламентные задания выполняются внутренними механизмами менеджера сервиса, как правило, без явного пользователя или от имени специальной служебной учётной записи. Влиять на это напрямую нельзя; при ошибках прав корректируйте роли и проверяйте, как код задания работает с разделением данных.

Варианты назначения пользователя

Явный служебный пользователь в свойстве задания

Рекомендуемый вариант: предсказуемые права, независимость от сеансов. Требует первичной настройки ролей

Пользователь по умолчанию из свойств базы в кластере

Подходит как общий запасной вариант для множества заданий, но все они получат одни права — сложнее соблюсти минимальность

Пустое свойство (без пользователя)

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

Что делать, если задание падает с ошибкой прав доступа

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

Если ошибка возникает в коде типовой конфигурации, проверьте, что служебный пользователь присутствует в справочнике «Пользователи», не заблокирован и входит в нужные группы доступа. Для заданий обмена также проверьте настройки узла плана обмена: некоторые механизмы хранят пользователя в самом узле, и он переопределяет пользователя задания.

Частые вопросы

Можно ли запустить регламентное задание от имени другого пользователя программно?

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

Почему в списке фоновых заданий поле пользователя пустое?

Это значит, что задание выполнилось без аутентифицированного пользователя — либо свойство «Пользователь» не заполнено и не задан пользователь по умолчанию в свойствах базы. Такие задания обычно работают с сильно ограниченными правами и часто являются причиной ошибок доступа.

Нужен ли служебному пользователю пароль?

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

Задание обмена выполняется от другого пользователя, чем указано в свойстве. Почему?

В типовых конфигурациях настройки обмена могут хранить собственного пользователя в узле плана обмена или в настройках сценария обмена. Этот пользователь имеет приоритет. Проверьте настройки конкретного обмена, а не только свойства регламентного задания.

Что будет, если заблокировать пользователя, указанного в задании?

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