Пользователь сообщает, что внешняя обработка или отчет не открывается: команда не видна, файл не выбирается, форма не появляется или выполнение обрывается сообщением об ошибке. В 1С причина редко сводится к одной настройке. Проверка доступа требует разделить видимость команды, право на запуск, доступ к файлу и режим исполнения кода. Ниже приведен порядок диагностики, который помогает администратору и разработчику последовательно сузить причину и не подменять проверку под рабочим пользователем тестом под администратором.
Содержание
Почему внешняя обработка или отчет могут не открываться
Сначала важно понять, как именно пользователь запускает объект. Один сценарий: внешний файл лежит на диске или в сетевом каталоге, и пользователь открывает его напрямую через интерфейс программы. Другой сценарий: обработка или отчет зарегистрированы в информационной базе через подсистему дополнительных отчетов и обработок либо подключены как расширение конфигурации. В каждом случае точки контроля различаются.
В типовой конфигурации внешняя обработка может подключаться несколькими путями: как файл, через подсистему дополнительных отчетов и обработок, как расширение конфигурации. У каждого пути свои проверки: видимость команды, право на объекты метаданных, разрешение на интерактивное открытие, доступ к файлу и условия исполнения кода. Названия разделов и состав команд зависят от конфигурации, релиза БСП, версии платформы и клиента.
Полезно сразу разделить три уровня ограничений. Первый уровень: права на объекты метаданных, включая элементы подсистемы дополнительных отчетов и обработок, команды и связанные справочники. Второй уровень: разрешение на интерактивное открытие внешних отчетов и обработок. Третий уровень: безопасный режим, привилегированный режим и контекст выполнения кода. Точные формулировки прав нужно сверять с документацией для используемой версии.
Три уровня ограничений, которые проверяют по отдельности
Первый уровень связан с ролями и профилями групп доступа. Пользователь может не видеть команду запуска, если у его роли нет прав на объекты метаданных, через которые работает подсистема дополнительных отчетов и обработок. В типовых конфигурациях на БСП доступ часто выдается через группы пользователей и профили групп доступа. Состав профилей и названия разделов зависят от релиза конфигурации и версии БСП.
Второй уровень: разрешение на интерактивное открытие внешних отчетов и обработок. Право на объект метаданных еще не гарантирует, что пользователь сможет выбрать внешний файл или открыть зарегистрированную обработку. В разных версиях платформы формулировки таких прав и поведение интерфейса могут отличаться. Если команда видна, но при выборе файла появляется отказ, проверяйте именно разрешение на интерактивное открытие.
Третий уровень: безопасный и привилегированный режимы исполнения кода. Безопасный режим ограничивает часть действий, которые может выполнять код внешней обработки. Привилегированный режим может обходить проверки прав в коде. Из-за этого тест под администратором, серверный вызов или запуск в другом клиенте не всегда совпадает с результатом у обычного пользователя. Проверять уровни нужно последовательно и фиксировать, на каком шаге пользователь теряет доступ.
Как администратору воспроизвести проблему под конкретным пользователем
Чтобы диагностика была достоверной, зафиксируйте исходные данные. Нужно понять, какая внешняя обработка или отчет не работает, откуда запускается объект, в какой информационной базе, через какой клиент, в какое время и под каким пользователем возникает проблема. Запишите текст сообщения и шаг, после которого появляется отказ. Без этой фиксации легко проверять не тот сценарий.
Проверять сценарий лучше под тестовым пользователем или в условиях, максимально близких к рабочему месту пользователя. Вход под администратором полезен как первый фильтр, но он не заменяет проверку под обычной учетной записью. Если под администратором все открывается, это не доказывает, что права настроены корректно. Возможны привилегированный режим, другой профиль, другой клиент или иной способ запуска.
Последовательность проверки удобно вести так:
- Воспроизведите симптом под тем же пользователем или близкой тестовой учетной записью.
- Определите шаг отказа: команда не видна, файл не выбирается, форма не открывается, запуск обрывается.
- Сравните группы пользователей и профили групп доступа у проблемного пользователя и у того, у кого сценарий работает.
- Проверьте способ запуска: файл с диска, объект в подсистеме дополнительных отчетов и обработок или расширение конфигурации.
- Просмотрите журнал регистрации за время попытки и сопоставьте события с пользователем и контекстом запуска.
После этого вернитесь к шагу, на котором появился отказ. Если ограничение возникает до открытия формы, вероятнее всего, дело в видимости команды или правах на объекты метаданных. Если форма открывается, но действие не выполняется, проверяйте безопасный режим, доступ к файлу и логику самой обработки. Если под одним пользователем сценарий работает, а под другим нет, сравнивайте профили и группы доступа.
Файл на диске и обработка, зарегистрированная в базе: разные точки контроля
Для внешнего файла вне информационной базы часть ограничений находится не в 1С, а в файловой системе и способе доставки файла. Пользователь может иметь права в базе, но не иметь фактического доступа к каталогу, сетевой папке или файлу на своем клиентском месте. Путь может устареть, файл могли заменить другой версией или переместить. Поэтому проверка прав в программе должна сочетаться с проверкой доступности файла с клиента пользователя.
Для обработки, зарегистрированной в базе, контролируются элементы подсистемы дополнительных отчетов и обработок, команды запуска и связанные объекты метаданных. Здесь администратору проще сравнить профили групп доступа и настройки подсистемы, потому что объект уже находится в информационной базе. Но право на объект метаданных не равно праву на запуск конкретного внешнего файла. Нужно отдельно смотреть, каким способом объект подключен и какие ограничения действуют для его выполнения.
Для расширения конфигурации проверяются права на объекты расширения и способ подключения. Возможности и названия элементов зависят от версии платформы и конфигурации, поэтому переносить настройки с одной базы на другую без сверки не стоит. Если расширение подключено, но пользователь не видит его команды, причина может быть в профиле, составе расширения или ограничениях клиента. Если команда видна, но запуск не происходит, снова проверяются режим исполнения и логика кода.
Безопасный и привилегированный режимы: почему тест под администратором обманывает
Безопасный режим ограничивает часть действий, которые может выполнять код внешней обработки. Даже при формально выданных правах обработка может не выполниться, если ее логика пытается совершить запрещенное в безопасном режиме действие. Внешне это иногда выглядит как отказ доступа, хотя причина в настройках безопасности, а не в профиле пользователя.
Привилегированный режим может обходить проверки прав в коде. Если администратор запускает обработку в привилегированном режиме, результат может отличаться от работы обычного пользователя. То же касается серверных вызовов и тестовых учетных записей с расширенными правами. Такой тест полезен как первый фильтр: он помогает понять, работает ли код в принципе, но не доказывает корректность доступа для рядового сотрудника.
Проверку нужно проводить в тех же условиях, в которых работает пользователь: тот же клиент, тот же способ запуска, те же настройки безопасности и тот же профиль доступа. Отделяйте ошибку доступа от ошибки кода, несовместимости версии обработки и ограничения безопасного режима. Для точных формулировок ограничений безопасного режима обращайтесь к документации платформы для используемой версии.
Критерии результата и ориентиры в журнале регистрации
Понятные критерии результата помогают не спорить о том, исправлена проблема или нет. Пользователь должен видеть команду или элемент запуска, если по сценарию они должны быть доступны. Он должен иметь возможность выбрать внешний файл или открыть зарегистрированную в базе обработку. Форма должна открываться без сообщения об отказе доступа. Обработка или отчет должны выполнять нужное действие, а в журнале не должно оставаться ошибок доступа, связанных с проверяемым сценарием.
В журнале регистрации ищите события, связанные с пользователем, временем попытки, отказом в доступе и контекстом выполнения. Сопоставляйте их с шагом, на котором возникла проблема. Названия событий и состав полей зависят от версии платформы, поэтому их нужно уточнять по документации. Если в журнале нет отказа, это еще не значит, что прав хватает: ограничение могло сработать в файловой системе, в клиенте или в безопасном режиме.
Короткий чек-лист диагностики выглядит так:
- воспроизвести проблему под пользователем или близкой тестовой учетной записью;
- проверить видимость команды и доступ к элементу запуска;
- сравнить профиль группы доступа и группы пользователей;
- проверить способ запуска: файл, объект в базе или расширение;
- учесть безопасный режим и контекст выполнения кода;
- просмотреть журнал регистрации и зафиксировать результат.
Главная мысль: права на объекты, запуск внешнего файла и режим исполнения проверяются отдельно. Тест под администратором полезен как первый фильтр, но не заменяет проверку в условиях пользователя. Если последовательно фиксировать шаг отказа и сравнивать профили, причину удается локализовать без подбора случайных настроек.
