Журнал действий — история операций в IZI CRM

Журнал действий — кто и что менял в вашем клубе

Журнал действий — раздел IZI CRM, который автоматически фиксирует каждую операцию сотрудника: создание акции, изменение продукта, работу со сменой и сотни других мутаций. Запись появляется сразу после выполнения операции без каких-либо настроек с вашей стороны — система работает на уровне Apollo-плагина и перехватывает все CRM-мутации. Каждая строка в журнале говорит вам: кто именно (имя и email сотрудника), что сделал (название операции), в каком клубе (если операция привязана к конкретному клубу), когда (дата и время с точностью до секунды) и с каким результатом — зелёная отметка для успешных операций, красная для завершившихся с ошибкой. Действия конечных посетителей клуба в журнал не попадают: он ведётся только по сотрудникам, работающим через CRM-интерфейс. Это принципиальное разграничение: вы видите только те изменения, которые реально влияют на конфигурацию клуба — тарифы, продукты, акции, настройки смен. Системные автоматические операции тоже фиксируются — в таких записях вместо имени сотрудника отображается пометка «Система», что позволяет отличить ручные действия от фоновых процессов. Раздел расположен в настройках организации и доступен пользователям с разрешением AUDIT_LOG_READ. Возможности фильтрации — по сотруднику, типу операции, клубу и периоду — позволяют за несколько секунд сузить тысячи записей до нужного события, а детальный просмотр каждой записи открывает точные входные параметры операции в JSON.

Что попадает в журнал

Система автоматически логирует все мутации CRM-пользователей. Операция попадает в журнал при соблюдении трёх условий:

• пользователь аутентифицирован с ролью CRM;
• запрос является мутацией (изменение данных, не чтение);
• мутация входит в перечень AuditLogOperationName — он генерируется автоматически из GraphQL-схемы и обновляется при добавлении новых функций.

Примеры операций, которые фиксируются: создание и обновление продуктов, управление акциями и промокодами, работа с тарифами, операции со сменами, изменения в настройках клуба. Системные автоматические операции (без конкретного сотрудника) тоже попадают в лог — в колонке «Пользователь» для них отображается пометка «Система».

Структура таблицы журнала

Таблица содержит пять колонок. Все заголовки кликабельны для сортировки — повторный клик меняет направление с убывания на возрастание и обратно.

Колонка	Что показывает
Дата и время	Момент выполнения операции; цветная полоска слева — зелёная (успех) или красная (ошибка)
Пользователь	Имя и email сотрудника; «Система» для автоматических операций
Операция	Человекочитаемое название операции, например «Обновление продукта»
Клуб	Клуб, в контексте которого выполнена операция; прочерк для операций уровня организации
Действия	Кнопка открытия деталей (появляется при наведении, если запись имеет детали)

По умолчанию таблица отсортирована по дате — сначала самые свежие записи. Пагинация — до 100 записей на странице.

Фильтрация записей

Панель фильтров расположена над таблицей и позволяет сузить выборку по четырём параметрам:

• Период — диапазон дат (обе границы включительно);
• Пользователи — выбор нескольких сотрудников одновременно;
• Операции — выбор одного или нескольких типов операций;
• Клубы — фильтр по конкретному клубу или нескольким клубам.

Фильтры комбинируются: можно одновременно выбрать период, нескольких сотрудников и тип операции, чтобы найти все попытки изменить конкретный объект за нужный промежуток времени.

Детали записи

Клик по строке или кнопка с иконкой в колонке «Действия» открывает модальное окно с двумя вкладками.

Вкладка «Обзор»

Содержит структурированную карточку записи:

• Дата и время — точный момент операции;
• Пользователь — имя и email (или пометка «Система»);
• Операция — человекочитаемое название и технический идентификатор операции;
• Клуб — если операция привязана к конкретному клубу;
• Ошибки — если статус ERROR, блок с сообщениями об ошибках и путями GraphQL, по которым они возникли;
• Связанные сущности — кнопки-теги с клиентом, заказом, транзакцией, девайсом, зоной или другими объектами, которых касалась операция. По клику открывается карточка этой сущности прямо из журнала.

Вкладка «Технические данные»

Два блока с JSON-содержимым:

• Входные параметры — переменные, с которыми была вызвана мутация (содержимое поля input);
• Результат выполнения — либо data с результатом успешной операции, либо errors с массивом ошибок GraphQL.

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

Как разобрать инцидент с помощью журнала

Типичный сценарий — кто-то изменил данные, и нужно понять кто и когда.

1. Откройте журнал действий в настройках организации.
2. Выставьте примерный период через фильтр дат.
3. В фильтре «Операции» выберите тип (например, «Обновление продукта»).
4. Просмотрите результаты — таблица покажет кто выполнял операции этого типа в выбранном периоде.
5. Нажмите на нужную строку и перейдите во вкладку «Технические данные» — там будут точные значения, которые передавались в момент операции.

Если операция завершилась с ошибкой (красная отметка), во вкладке «Обзор» сразу виден блок с текстом ошибки. Это помогает понять, что именно не дало операции выполниться.

Права доступа к журналу

Раздел «Журнал действий» отображается только пользователям с разрешением AUDIT_LOG_READ на уровне организации. Разрешение задаётся в настройках ролей и может быть назначено как владельцу, так и отдельным административным ролям.

Просматривать записи может только тот, у кого есть это разрешение — это намеренное ограничение: лог содержит технические детали операций, включая входные параметры.

Связанные разделы

• Роли и права доступа — как настроить кто видит журнал
• Смены — операции открытия и закрытия смен тоже фиксируются в журнале
• Команда и сотрудники — управление составом команды и их ролями