Есть что-то, чем можно собрать лог обращений по объектам метаданных, в идеале с ролями (чтения/запись) по конкретному пользователю?

Новый профиль?

Чисто теоретически рассуждая, можно запустить технологический журнал работы для конкретного пользователя ОС - если файл настроек разместить в C:\Users\ИмяЮзверя\AppData\Local\1C\1cv8\conf... Такого опыта у меня нет, но опять же чисто теоретически, можно фильтра настроить так, чтобы при анализе не закопаться...

(0) А мне чисто практически возникает вопрос: Зачем?

От ответа на этот вопрос зависят и рекомендации, как это сделать.

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

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

(5) дурачки из датамобайла тоже говорят ставь полные, методом тыка за полчаса нашлась роль

(5) обмен на миллион строк... он же вероятно исполняется на серверной стороне и фоновым заданием. Может есть смысл куда-то прикрутить повышение привелегий, а не назначение на зареганного в базе пользователя права?

Звучит как ТС надо УстановитьПривелигерованныйРежим() и не мучать нас и себя

(8) УстановитьПривилегированныйРежим()

Хуже только "соответствие" ><

А чем привилегированный режим для неизвестного кода отличается от полных прав ?
На самом деле, если код чисто серверный,то можно собрать тексты запросов и дать права на таблицы (объекты,которые в них упоминаются)
Если будет обращение к объектам,то также давать права на объекты.
Но,во-первых,роли могут проверяться в коде,во-вторых,даже нормальное исполнение кода не даст гарантии,что потом,при изменении данных,обращения не пойдут в другие таблицы,которые первоначально не рассматривплись.

(10) все верно, но я нарочно уточнил и получил ответ, что это в обмене. Т.е. пользователь не тот, который что-то регисртирует, а только такой, который читает и отправляет.
И для такого на чтение по Ролям там скорей всего не должно возникать проблемы. Ну иначе разработчик об этом уже узнал бы.
Здесь больше интересны Роли не на той стороне, что на Источнике, а на той, где Приемник.

(0) Я подобные задачи решаю путем запуска сеанса под проблемным пользователем (с подменой пароля). Выполняю операцию. Получаю очередную ошибку доступа. Смотрю ее журнале регистрации и сразу исправляю - даю одной из ролей пользователя нужное право. И повторяю так до успешного завершения операции.

(0) там может половина кода исполняться в привилегированном режиме и собранные роли вообще не будут означать, что к ним надо будет давать доступ.

(12) "так и я могу!"©
геморно же! Неужели нет другого решения?

(10) Тем что - какого чёрт код "неизвестен" если пишешь его ты, то, что режим включается и выключается когда тебе (программисту) нужно, и собственно сам этот режим и придуман для описанной цели - когда временно надо отключить проверку по правам и выполнить код в любом случае. Те самые "временные полные права". Зачем изобретать велосипеды тут я не понимаю)

Сотрудник уходит в отпуск... его обязанности назначают исполнять другому сотруднику (или распределяют между другими сотрудниками)... я узнаю об этом последним... Это, типа, я поделился наболевшим :)

К чему это я?

Методом, указанным в (12), решать можно тогда, когда обращения юзвера конкретно конкретизированы. У автора другая проблема: он не владеет этой информацией и желает её узнать (собрать по факту на основе некоторой статистики).

(16) ага, особенно радует "временное распределение между сотрудниками", причем "исключительное"

(16) ну там же не просто некоторая уже постфактум статистика будет.

Наверняка, что разработчик обменов от лица Интегратора не остановится и будет и дальше вносить изменения в программный код своих обработок. Это погоня за выдачей ему прав будет вечной.

И погоня эта называется аудит. Т.е. вне зависимости от того, каким именно способом будет решаться проблема обхода ошибок при получении данных объектов, аудит придется проводить с некоторой периодичностью. Или не придется. Как этого захочет Заказчик.

Ну если прям очень хочется, то есть такое. Надо настроить регистрацию события "Доступ.Доступ" в журнале регистрации.
Это можно сделать через "Настройка журнала регистрации (ИР)"
https://i.imgur.com/7vPfNtk.png

(15) Суть не дать полные права временно
А выяснить какие нужны права для конкретной операции чтобы по списку операция выдать юзеру минимально необходимые права

(19) + Но журнал будет расти прям очень быстро, т.к. по пользователю там к сожалению нельзя включить отбор.

(12) Каким образом "(с подменой пароля)" ?

(22) Через "Редактор пользователей (ИР)"
https://i.imgur.com/DpNPecl.png

(23) вопрос был каким образом технически выполняется для платформы 1С эта "подмена пароля"?

(24) Сохранением хеша пароля. Заменой пароля. Запуском сеанса. Восстановлением хем пароля.

(25) У фирмы 1С не было претензий к подобному функционалу в "ИР"?

(26)+ Интересно как они в версии "z" сертификацию прошли...

(0) у обработки обмена закрытый модуль? Что мешает проанализировать код?
Если таки закрыт, а задача бы стояла я бы создал отдельную через РИБ сливал бы в нее изменения, "интегратора" бы подключил к отдельной базе, а далее либо ТЖ, либо профайлер к этой базе и анализ чтений/записей объектов/таблиц.

(26) Фирма 1С мне не предъявляла каких либо претензий по ИР. Но согласен, что техника эта представляет сложность для аудита. В планах есть задача при такой подмене всегда оставлять след в журнале регистрации.

(19) Спасибо за наводку. Нужная вещь иногда.