8.2.15.294

С некоторых пор в журнале регистрации стало твориться непонятное.
Входит пользователь Иванов.
Работает.
Выходит.

В журнале регистрации:
Пользователь: Петров
Событие: Сеанс. Аутентификация
Данные: Имя: Иванов

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

Что творится с журналом регистрации? Может кто с подобным сталкивался? Прошу помощи.

ну судя по "...И в документах которые он создает в соответствующее поле автоматически подставляется текущий пользователь, а именно Иванов..." дело не в ЖР

как обычно - начать с "почистить кэш"

(1) А не наоборот? Работает Иванов, в документы подставляется Иванов, а в ЖР отражается Петров.

(3) не так прочитал я значит.
ну чистку кеша я бы все-равно попробовал в первую очередь

(0) так бывает, когда переименовываешь пользователей. Самый верный сейчас вариант - удалить этого пользователя и создать заново. И больше - не переименовывать ни когда.

(5) Это не только с этим пользователем. Закономерности не увидел. Причем бывает даже такое, что например при просмотре ЖР за 5 января: входил и работал Сергеев.
А в ЖР:
Пользователь: Андреев
Событие: Сеанс. Аутентификация
Данные: Имя: Сергеев

Притом что Андреева в январе в базе не было, он был создан только в апреле.

(6) так вы с нуля создали этого андреева или сергеева переименовали?

(6) ну, значит, вы систематически переименовываете пользоватей

Еще в пользовательском режиме и в конфигураторе имена могут отличаться. Не переименовывай.

(6) Андреев был создан как новый пользователь. В базе теперь существуют оба.
(8) Пользователи периодически переименовываются. Не часто - но бывает. Нигде от 1С не встречал рекомендаций этого не делать.
(9) Переименовывать иногда необходимо.

Как это все можно исправить?
Кэш не предлагать чистить, т.к. пару месяцев назад был переезд на новое железо. Кэш "свежий".

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

>пару месяцев назад
>кэш свежий

серьезно?

(12) Ну учитывая, что описанная проблема распространяется например на январь, а кэш "мартовский", то как он может влиять?

(13) Да никак, ты жеж комментируешь в теме человека с проблемой, которой у тебя нет. Ведь так?

(14) Не понял выпада

(13) ты представления не имеешь, о каком кэше речь.
Ну, да он и ни при чем тут.

(16) Ну так поясни о каком кэше речь? Если не сложно.

(17) о кэше конфигурации. Он ни при чем. Причина в переименовании пользователей.
Добродетельные люди не переименовывают пользователей.

Теперь вообще жесть.
Открыл тот же журнал регистрации в режиме предприятие (обычное приложение). И ситуация, описанная в (0) изменилась...
Вместо:
Пользователь: Петров
Событие: Сеанс. Аутентификация
Данные: Имя: Иванов
Стало:
Пользователь: <Неопределено>
Событие: Сеанс. Аутентификация
Данные: Имя: Иванов

Как такое может быть?

Проверил ЖР до момента первого возникновения такого "глюка".
Переименованные пользователи выглядят так:

Пользователь: Иванов (после переименования)
Событие: Сеанс. Аутентификация
Данные: Имя: Иванов (до переименования)

И это меня полностью устраивает. Т.к. пользователь определяется правильно.

А глюки описанные в (0) происходят совсем не с переименованными.

Подытожу... Может кому будет полезен мой опыт.

Решил разбираться основательно.
На инфостарте нашел описание формата файлов ЖР и файла описания: http://catalog.mista.ru/public/182061/
Проанализировав в Excel файл описания понял с какого момента у меня начались глюки: с кода пользователя 523.
У этого же автора скачал обработку "Анализ и редактирование файлов журнала регистрации 1С 8.1/8.2": http://catalog.mista.ru/public/181455/
Запустил в ней чтение файла описания.
На середине обработки вывалился по ошибке, в отладчике нашел ошибочную строку.
Нашел ее в файле и увидел, что из-за какого-то сбоя в ней присутствуют лишние неопознанные символы: "{13,80,152}          ," вместо "{13,80,152},".
При наличии этих символов при каждом входе новым пользователем (созданным после того временного отрезка, когда в файле появилась глючная запись) либо иногда (пока не выяснил в каких случаях) при входе старым пользователем ему присваивался код пользователя между 523 и 536, и как итог получали в ЖР действия производил один пользователь, а регистрировались они за другим.
Когда убирал "лишние" символы, то при входе новым пользователем запись создавалась только единожды и с новым кодом (первым свободным), а при входе старыми пользователями запись в файле описаний не создавалось. Т.е. вернулись к штатному поведению файла описания.
В этом же файле описаний можно "бороться" с последствиями переименования пользователей: в нем будет две записи с одинаковым кодом и разными наименованиями (до и после переименования), при необходимости лишнюю можно удалить.
В файле описаний убрал двойные записи переименованных пользователей (те, что были до переименования) и присвоил новые коды пользователям, которые были созданы после возникновения "глючной записи" в файле описания.

Исправление логов.
Выгрузил в Эксель ЖР. Оставил записи с событием "Сеанс.Аутентификация". В полученных записях оставил лишь те, где имя (входа), указанное в поле "Данные", не совпадает с указанным в "Пользователь". А дальше я получил связку Дата (для определения нужного мне файла лога) - Сеанс - ИмяПользователя (из данных) -КодПользователя (из файла описаний).
Немного доработал обработку, чтобы она в журнале заменяла в записях с нужным номером сеанса код пользователя на нужный и все.
После обработки обработкой файлов ЖР с начала года (а глюк пошел именно с 01.01.2017) у меня наведен порядок.

(21) Какой во всем этом смысл, если "Пользователи периодически переименовываются. Не часто - но бывает" (8)?

+(22) Ну т.е. со значительной вероятностью глюк повторится

(23) Этот глюк никак не связан с переименованием.
Пользователи переименовывались периодически на протяжении многих лет.
Определив когда начали появляться глюки в ЖР начал восстанавливать события и именно в тот день были проблемы с жесткими дисками, сервер аварийно останавливался, после чего восстанавливали его работоспособность. Вероятнее всего, что именно тогда и появилась в файле описания та запись, которая влияла на корректность работы ЖР.
А разобравшись как и где хранятся данные о переименованных пользователях я для себя сделал вывод - что переименование не может являться причиной моего (а возможно и других) глюков в работе ЖР.