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

Чтобы запустить отладку под другим пользователем, в Конфигураторе откройте Сервис → Параметры → Запуск 1С:Предприятия и впишите имя и пароль нужного пользователя в поля «Пользователь» и «Пароль». После этого Отладка → Начать отладку (F5) откроет 1С:Предприятие уже от его имени, а точки останова будут срабатывать как обычно.

Второй способ — командная строка: клиент запускают с ключами /N (имя), /P (пароль) и /Debug, а Конфигуратор подключается к сеансу сам. Первый вариант удобен для разовой проверки, второй — когда нужно быстро переключаться между несколькими пользователями или отлаживать клиент на другом компьютере. Всё ниже относится к платформе 8.3 и не зависит от конфигурации: БП, ЗУП, УТ и самописные базы отлаживаются одинаково.

Что подготовить до запуска отладки

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

Что проверить заранее:

• 🔑 Аутентификация 1С:Предприятия. В карточке пользователя должна стоять галочка входа по логину и паролю. Если у пользователя включена только аутентификация операционной системы, ключи /N и /P не сработают.
• 👤 Пароль известен. Сбрасывать пароль живому сотруднику ради отладки — плохая идея: он не сможет войти утром.
• 🧩 Права на запуск клиента. У ролей пользователя должно быть право на нужный вид клиента (тонкий, толстый, веб). Иначе вход оборвётся ещё до первой точки останова.
• 💾 Копия базы. Отладку с правками кода и данных ведите в копии, а не в рабочей базе.

Тестовый пользователь вместо реального

Надёжный приём практика — завести отдельного пользователя «Тест_Кладовщик» и дать ему ровно те же права. В типовых конфигурациях на БСП (БП 3.0, ЗУП 3.1, УТ 11) пользователи и права настраиваются в разделе Администрирование → Настройки пользователей и прав.

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

В самописной конфигурации без БСП пользователя создают прямо в Конфигураторе через Администрирование → Пользователи, роли отмечают на вкладке «Прочие».

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

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

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

Откроется 1С:Предприятие под указанным пользователем. Код с точками останова выполняется в его сеансе, с его ролями и ограничениями.

Как убедиться, что сеанс действительно чужой

Остановитесь на любой точке останова и откройте окно вычисления выражения (Shift+F9). Проверьте три выражения:

ПользователиИнформационнойБазы.ТекущийПользователь().Имя
РольДоступна("ПолныеПрава")
ПривилегированныйРежим()

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

Способ 2. Запуск отладки 1С из командной строки

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

Протокол выбирают в Конфигураторе: Сервис → Параметры, вкладка «Отладка». После перехода на HTTP Конфигуратор использует сервер отладки dbgs.exe, по умолчанию на порту 1550.

Пример .bat-файла для файловой базы и тонкого клиента :

@echo off
set BASE="D:\Bases\Torg_copy"

rem Запуск под пользователем Тест_Кладовщик с подключением к отладчику
"C:\Program Files\1cv8\8.3.24.1342\bin\1cv8c.exe" ENTERPRISE /F%BASE% /N"Тест_Кладовщик" /P"123" /Debug -http /DebuggerURL "http://localhost:1550"

Номер версии в пути замените на свой. Для клиент-серверной базы вместо /F указывается /S"имя_сервера\имя_базы".

Ключ /WA- полезен, если у вас самого настроен вход через Windows: без него платформа может пустить вас под вашей учёткой, а не под тестовой.

Подключение Конфигуратора к уже запущенному клиенту

Если клиент запущен с /Debug, его сеанс появится в Конфигураторе в окне Отладка → Подключение. В списке предметов отладки видно базу, тип предмета (клиент, сервер) и пользователя. Выделите нужный и подключитесь.

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

Чем отличается отладка в тонком, толстом и веб-клиенте

Одна и та же ошибка прав может вести себя по-разному в зависимости от того, где выполняется код.

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

В клиент-серверной базе серверный код живёт в рабочих процессах кластера. Чтобы поймать его отладчиком, служба агента сервера должна быть запущена с ключом -debug (для HTTP — -debug -http). Ключ прописывают в параметрах запуска службы агента сервера 1С.

Есть и обратная сторона. Если в клиент-серверной базе включить автоматическое подключение к серверным предметам отладки, точки останова начнут срабатывать в серверных вызовах любых сеансов, а не только тестового. Пользователи рабочей базы просто «зависнут» на остановке. На продуктивном сервере так не делают.

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

Ограничение доступа на уровне записей (RLS) — частая причина, ради которой и нужна отладка под чужими правами. У администратора с полными правами ограничения не действуют, поэтому под ним запрос возвращает всё.

Как RLS проявляется в коде:

• 📉 Запрос с ВЫБРАТЬ РАЗРЕШЕННЫЕ молча отбрасывает недоступные строки. Ошибки нет, просто в отчёте или списке меньше данных.
• 🛑 Запрос без РАЗРЕШЕННЫЕ при попадании на запрещённые записи падает с ошибкой Нарушение прав доступа!.
• 📄 Чтение объекта по ссылке (Ссылка.ПолучитьОбъект(), обращение к реквизиту через точку) на запрещённой записи тоже даёт отказ.

Приём: один и тот же запрос с флагом и без

Остановитесь в сеансе тестового пользователя перед выполнением запроса. В окне вычисления выражения выполните текст запроса дважды: как он есть и с добавлением РАЗРЕШЕННЫЕ после ВЫБРАТЬ. Если с флагом выборка пустая или короче, а без флага — ошибка, значит, дело в RLS, а не в ролях на объект.

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

Журнал регистрации как помощник отладчика

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

Где открыть журнал:

• в Конфигураторе — Администрирование → Журнал регистрации;
• в БП 3.0, ЗУП 3.1, УТ 11 — Администрирование → Обслуживание → Журнал регистрации.

Что смотреть:

1. Установите отбор по пользователю и интервалу, когда воспроизводили ошибку.
2. Ищите события «Доступ. Отказ в доступе»: в них указан объект метаданных и действие, на которое не хватило прав.
3. Проверьте события сеанса «Аутентификация» и ошибки аутентификации — так видно, под кем на самом деле был выполнен вход.
4. Если событий мало, проверьте уровень регистрации. Он задаётся в Конфигураторе: Администрирование → Настройка журнала регистрации. Для разбора временно включите регистрацию всех событий, потом верните прежний уровень.

Сопоставьте время события с моментом, когда отладчик остановился на точке. Так связывается строка кода и конкретный отказ в правах.

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

Ещё одна ловушка — привилегированный режим. Если проблемный фрагмент вызывается из общего модуля с флагом «Привилегированный», права в нём не проверяются ни у кого. Тогда ищите отказ выше по стеку вызовов (Ctrl+Alt+C открывает окно стека), в коде, который выполняется до входа в такой модуль.

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