Налаштування логування дій користувачів 1С-Бітрікс
Коли на сайті 200+ контент-менеджерів та адміністраторів, питання «хто змінив ціну на товар вчора о 17:30» без логування не має відповіді. Штатний журнал подій Бітрікса фіксує далеко не всьо, а те, що фіксує — зберігає без зручної фільтрації. Задача — налаштувати повноцінне логування: хто, коли, що зробив, які значення були до та після.
Штатні засоби: модуль «Журнал подій»
Бітрікс з коробки пише подiї у таблицю b_event_log. Включається у налаштуваннях головного модуля: Налаштування → Налаштування продукту → Налаштування модулів → Головний модуль → вкладка «Журнал подій».
Що логується штатно:
- Авторизація / вихід (
USER_LOGIN,USER_LOGOUT) - Помилки авторизації (
USER_LOGIN_FAILED) - Зміна налаштувань модулів (
MODULE_RIGHTS_CHANGED) - Дії з файлами через файловий менеджер (
FILE_DELETE,FILE_EDIT) - Операції з користувачами (
USER_ADD,USER_EDIT,USER_DELETE)
Що НЕ логується:
- Зміни елементів інфоблоків (товари, статті, новини)
- Зміни замовлень (зміна статусу, редагування)
- Зміни цін та остатків
- Дії в модулі CRM (при наявності)
Саме ці дії зазвичай і потрібно відслідковувати.
Розширення логування через обробники подій
Для логування змін в інфоблоках підписуємося на події модуля iblock:
-
OnBeforeIBlockElementUpdate— отримуємо дані ДО зміни -
OnAfterIBlockElementUpdate— фіксуємо факт зміни
Пара подій потрібна для запису diff — які поля змінилися та з яких значень на які. Обробник реєструється у /local/php_interface/init.php через AddEventHandler() або у файлі events.php модуля.
Ключові поля для логування змін елемента інфоблоку:
| Поле | Чому логувати |
|---|---|
| NAME | Перейменування товару |
| ACTIVE | Включення/виключення |
| SORT | Зміна сортування |
| PROPERTY_PRICE / PRICE | Зміна ціни |
| PROPERTY_* | Будь-які властивості інфоблоку |
| DETAIL_TEXT | Зміна опису |
Для запису використовуємо CEventLog::Add():
CEventLog::Add([
'SEVERITY' => 'INFO',
'AUDIT_TYPE_ID' => 'IBLOCK_ELEMENT_UPDATE',
'MODULE_ID' => 'iblock',
'ITEM_ID' => $elementId,
'DESCRIPTION' => json_encode([
'user_id' => $GLOBALS['USER']->GetID(),
'changes' => $diff,
], JSON_UNESCAPED_UNICODE),
]);
Записи потрапляють у ту ж таблицю b_event_log та видимі у штатному інтерфейсі журналу подій.
Логування дій з замовленнями
Модуль sale має власні подiї: OnSaleOrderSaved, OnSaleStatusOrder, OnSalePayOrder. Для повного аудиту замовлень підписуємося на OnSaleOrderSaved — воно спрацьовує при будь-якому збереженні замовлення.
Всередині обробника доступний об'єкт \Bitrix\Sale\Order, з якого отримуємо поточний стан. Для порівняння з попереднім — завантажуємо замовлення з БД до збереження (у OnBeforeSaleOrderSaved).
Ротація та зберігання
Таблиця b_event_log росте швидко. На активному магазині (1000+ замовлень/день, 50+ редакторів) — до 100 000 записів на місяць. Налаштування ротації:
- Час зберігання — задається у налаштуваннях журналу подій (за замовчуванням не обмежено)
-
Ручна очистка —
CEventLog::CleanUp($days)через агент - Рекомендація — зберігати 90 днів у Бітриксі, старі записи архівувати в окремої таблиці або файлі
Швидка перевірка налаштування
Після підключення обробників: змініть тестовий товар в админці, потім відкрийте Налаштування → Інструменти → Журнал подій, відфільтруйте по типу IBLOCK_ELEMENT_UPDATE. Запис повинна містити ID елемента та diff змін у описі.
Налаштування базового логування займає один робочий день. Сюди входить написання обробників для інфоблоків та замовлень, перевірка на тестових даних та налаштування ротації.