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

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

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

Материал ориентирован на разработчиков и администраторов, работающих с платформой 8.3. Приведённые приёмы применимы и к файловым, и к клиент-серверным базам, но есть различия в настройке, о которых сказано отдельно.

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

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

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

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

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

Первый шаг — настроить конфигуратор так, чтобы он подхватывал чужие сеансы без ручного подключения. Откройте базу в конфигураторе под своей учётной записью разработчика и перейдите в меню «Отладка» → «Подключение…». В окне подключения нажмите кнопку «Автоматическое подключение…».

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

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

1. 1
   Откройте конфигуратор под учётной записью разработчика
2. 2
   Меню «Отладка» → «Подключение…» → кнопка «Автоматическое подключение…»
3. 3
   Отметьте нужные типы предметов отладки и нажмите ОК
4. 4
   Запустите отладку: «Отладка» → «Начать отладку» (F5) или перейдите сразу к запуску пользовательского сеанса
5. 5
   Убедитесь, что после входа пользователя его сеанс появился в окне «Подключение» как подключённый

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

Параметры командной строки /N и /P

Самый контролируемый способ — запустить клиентское приложение с явным указанием имени пользователя. Параметр /N"ИмяПользователя" задаёт логин, /P"Пароль" — пароль (если пароль пустой, параметр /P можно опустить). Пример ярлыка:

"C:\Program Files\1cv8\8.3.22.1750\bin\1cv8.exe" ENTERPRISE /F"C:\Bases\Trade" /N"ИвановИИ" /P"123"

Для клиент-серверной базы вместо /F используется параметр /S с указанием сервера и имени базы: /S"Server\Base". Важно: путь к исполняемому файлу и номер версии платформы у вас будут свои — подставьте актуальные значения из каталога установки.

1cv8.exe ENTERPRISE /S"srv1c\TradeBase" /N"ПетроваАС" /P"secret" /DebuggerURL"localhost"

Запуск от имени другой Windows-учётной записи (runas)

Если пользователь аутентифицируется через Windows (режим «Выбирать из списка» отключён, используется аутентификация операционной системы), параметры /N и /P не помогут. Тогда сеанс запускают от имени другой учётной записи Windows командой runas:

runas /user:DOMAIN\ivanov "C:\Program Files\1cv8\...\bin\1cv8.exe ENTERPRISE /S\"srv1c\TradeBase\""

Потребуется пароль доменной учётной записи пользователя. Если его знать нельзя (что нормально с точки зрения безопасности), используйте альтернативу: попросите пользователя самостоятельно запустить сеанс на своём компьютере, а вы со стороны конфигуратора подключитесь к нему через окно «Отладка» → «Подключение…». Для этого пользователь должен запустить 1С с ключом /DEBUG (см. следующий раздел).

Сеанс запускает сам пользователь

Наиболее безопасный вариант для рабочей базы: пользователь открывает 1С на своём рабочем месте, а разработчик подключается к его сеансу удалённо. Для этого в настройках информационной базы в списке баз (кнопка «Настройка» в окне запуска) или в конфигураторе через «Администрирование» → «Параметры информационной базы» устанавливается разрешение на отладку, а клиент запускается с ключом командной строки /DEBUG (и для тонкого клиента дополнительно проверьте адрес отладчика).

Включение режима отладки на сервере 1С

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

На Windows это делается через реестр: в ветке службы агента сервера (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent) в параметре ImagePath добавьте -debug к строке запуска ragent.exe, затем перезапустите службу. На Linux ключ добавляется в скрипт или unit-файл запуска srv1cv83.

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

Отладка фоновых заданий и веб-клиента

Фоновые задания — частый источник «невидимых» ошибок: код исполняется от имени пользователя, указанного в свойствах регламентного задания, либо от имени того, кто запустил фоновое задание программно. Чтобы отладить такой код, в окне «Отладка» → «Подключение…» отметьте в автоматическом подключении пункт «Фоновые задания» и дождитесь очередного запуска задания.

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

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

Проверка результата и типичные ошибки

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

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

Ограничения и безопасные практики

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

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

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

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