дать право на чтение журнала регистрации но что бы не был доступен просмотр журнала?
подскажите как реализовать?не могу найти и возможно ли такое?

(0) Не давай пользователю права на ЖР, а чтение делай из привилегированного модуля, как вариант.

(1) у пользователя просто нету сейчас прав на журнал регистрации

Может уже задачу расскажешь

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

(4) ну тогда тебе в (1) уже сказали.Хотя можно и без журнала,в свойства можно писать те же

опять же дальше добавлять видимо редактирование,пометка на удаление и т.д

(4) >> решил читать это все из ЖР

Решение неверное.
По мере роста журнала регистрации скорость работы этого решения будет очень сильно падать. В зависимости от интенсивности работы с базой через 2-3 года пользователь, ожидая результата, будет успевать попить кофе, покурить, и еще кучу всяких дел переделать. А если в этот момент кто-то интенсивно пишет в ЖР, то пользователь может вообще не дождаться ответа.
Надо понимать, что ЖР - это отдельная база данных, которая была сделана таким образом, чтобы туда быстро писать.
А еще любое завязывание логики на ЖР ставит жестко два вопроса:
1. о резервном копировании ЖР (мало кто этим заморачивается)
2. о склеивании нескольких ЖР в случае если придётся обрезать журнал регистрации, или переносить базу с одного сервера на другой (или заморачиваться с переносом журнала регистрации), или падения журнала регистрации (такое иногда бывает).


Альтернативы:
1. Влепить свой реквизит "Автор" в справочник, который заполнять в подписке на событие ПередЗаписью при условии Если Новый().
2. Состряпать свой регистр сведений, куда добавлять записи аналогично п.1
3. Если конфа типовая на БСП, то там есть версионирование. Можно включить версионирование по нужным объектам и брать данные из регистра ВерсииОбъектов с отбором по типу метаданных, автору и номеру версии (брать первую). Но тут потребуется некое первоначальное заполнение версий. Иначе все первые версии это будут не реально первые, а измененные впервые после включения версионирования.

(7) спасибо за предложение которые написали)

(7) эти сведения устарели лет на 5 и уже являются ложными.

+(9) которые "По мере роста журнала регистрации скорость работы и блаблабла"

тем более, что отбор событий по одному пользователю по одному справочнику за сегодня не зависит от размера ЖР

лучше юзать версионирование

А напомните там же очищаются периодически версии

главное будет кто создал,а потом кто что с ним делал,это уже второстепенно )

(14) свойства

(9) (10) >> эти сведения устарели...
(11) >> отбор событий по одному пользователю по одному справочнику за сегодня не зависит от размера ЖР

Если бы... 5 лет назад на ЖР старой версии (текстовом) просто всё было ещё хуже.

Любой отбор сложнее "Пользователь + Объект (строгое равенство)" за неограниченный период приводит к вставанию журнала колом. А автору надо не по объекту, а по типу объектов.
Личный опыт. Журнал 52Гб. Великоват конечно. Но и на меньших объемах было не сильно лучше.

Конечно при условии, что с базой никто не работает и объем журнала ограничивается парой Гб, всё будет летать.

(16) отбираю по типу объекта,дата день..максимум неделя.
и типу события

поэтому вроде тупить не должно)проверим на практике)

+ к (16) Да даже, если всё будет летать, навешивание логики работы на ЖР является неверным. По причинам, изложенным в (7) - необходимость архивирования, отказ от возможности обрезания, проблемы в случае его умирания или переноса базы.

(17) >> дата день..максимум неделя.

Если так, то будет работать быстро (относительно).

там же вроде индекс есть по объекту

(16) почему устарели?

(20) Откуда день? Я так понимаю эта информация нудно всегда, что вот этого контрагента создал 2 года назад менеджер Вася.
Все равно летать будет?

(19) нет там логиуки ни какой. Там как раз то, для чего ЖР придуман.

(22) потому, что ЖР уже чуть ли не черте сколько лет не в файлах хранится, в БД (хоть и отдельной). С индексами и скоростью доступа, не идущей ни в какое сравнение.
Ни какого "всегда" там не надо. Уже даже вчерашние розничные контрагенты наиух не нужны.

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

(21) И что, что есть?
Там по сути одна большая таблица EventLog.
Все остальные - вспомогательные и маленькие.
В условиях, когда запрос не ограничивается по периоду (или период очень большой), сам ЖР достаточно велик и при этом туда одновременно пишут события много пользователей (сеансов), получаем тормоза.

Кроме того, у автора отбор не по объекту, а по типу объекта. Но за маленький период (собственно это должно его спасти от тормозов).

Поэкспериментируйте. Сделайте отбор по пользователю, метаданным (например, справочник Контрагенты) и событию Данные.Добавление.
Ответа ждать приходится очень долго.
Хотя если добавить период, результат будет получен быстро.