Налаштування логування дій користувачів 1С-Бітрікс
На проєктах з 200+ контент-менеджерів та адміністраторів питання «хто змінив ціну на товар вчора о 17:30» без логування не має відповіді. Штатний журнал подій Бітрікса фіксує далеко не все, а те, що фіксує — зберігає без зручної фільтрації. Наприклад, ви не дізнаєтеся, хто зняв товар з публікації або змінив його назву. Без детального аудиту неможливо довести провину конкретного співробітника або відновити історію змін. Ми вирішуємо це завдання: налаштовуємо повноцінне логування з кастомними обробниками, ротацією та архівацією. За 5 років роботи ми виконали понад 50 проєктів по Бітрікс, тому гарантуємо прозорість кожної дії. Наші інженери розроблять обробники для інфоблоків, замовлень та CRM, додадуть diff-порівняння та налаштовувані фільтри. Зв'яжіться з нами — ми підберемо оптимальну конфігурацію логування під ваш проєкт.
Чому штатного журналу подій недостатньо?
Бітрікс з коробки пише події в таблицю b_event_log. Вмикається в налаштуваннях головного модуля: Налаштування → Налаштування продукту → Налаштування модулів → Головний модуль → вкладка «Журнал подій».
Штатно логуються такі події:
- Авторизація / вихід (
USER_LOGIN,USER_LOGOUT) - Помилки авторизації (
USER_LOGIN_FAILED) - Зміна налаштувань модулів (
MODULE_RIGHTS_CHANGED) - Дії з файлами через файловий менеджер (
FILE_DELETE,FILE_EDIT) - Операції з користувачами (
USER_ADD,USER_EDIT,USER_DELETE)
Ці події покривають лише системні дії. Зміни контенту — товарів, статей, цін — залишаються за кадром. Без кастомних обробників ви залишаєтеся сліпими до більшості змін.
За кадром стандартної конфігурації залишається наступне:
- Зміни елементів інфоблоків (товари, статті, новини) — ключовий пробіл
- Зміни замовлень (зміна статусу, редагування)
- Зміни цін та залишків
- Дії в модулі CRM (за наявності) — контакти, угоди, ліди
У комерційних проєктах саме ці зміни найчастіше потребують аудиту. Наше кастомне рішення в 3 рази ефективніше стандартного, оскільки додає diff-порівняння та гнучкі фільтри. Записи зберігаються із зазначенням точного часу, IP-адреси та сесії користувача.
Як розширити логування через обробники подій?
Для логування змін в інфоблоках підписуємося на події модуля 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 і видимі у штатному інтерфейсі журналу подій.
Приклад повного коду обробника для інфоблоків
AddEventHandler("iblock", "OnBeforeIBlockElementUpdate", "MyLogIBlockBeforeUpdate"); AddEventHandler("iblock", "OnAfterIBlockElementUpdate", "MyLogIBlockAfterUpdate"); // ... rest of code Як налаштувати логування дій із замовленнями?
Модуль sale має власні події: OnSaleOrderSaved, OnSaleStatusOrder, OnSalePayOrder. Для повного аудиту замовлень підписуємося на OnSaleOrderSaved — воно спрацьовує при будь-якому збереженні замовлення. Всередині обробника доступний об'єкт \Bitrix\Sale\Order, з якого отримуємо поточний стан. Для порівняння з попереднім — завантажуємо замовлення з БД до збереження (в OnBeforeSaleOrderSaved). Таким чином фіксуються всі зміни: статус, склад, адреса доставки, ціни.
Ротація та зберігання
Таблиця b_event_log росте швидко. На активному магазині (1000+ замовлень/день, 50+ редакторів) — до 100 000 записів на місяць. Налаштування ротації:
- Час зберігання — задається в налаштуваннях журналу подій (за замовчуванням не обмежено)
- Ручне очищення —
CEventLog::CleanUp($days)через агент - Рекомендація — зберігати 90 днів у Бітрікс, старі записи архівувати в окрему таблицю або файл
Оптимальна конфігурація зберігання:
| Тип даних | Термін зберігання | Метод архівації |
|---|---|---|
| Активні записи | 90 днів | Залишаються в b_event_log |
| Старі записи | До 1 року | Копіюються в архівну таблицю b_event_log_archive |
| Архів | Не обмежено | Експорт у CSV та видалення з БД |
Що входить у налаштування логування?
Ми надаємо повний комплект робіт:
- Розробка кастомних обробників для інфоблоків, замовлень та CRM
- Налаштування ротації та архівації записів
- Тестування на тестових даних зі створенням еталонних записів
- Документація щодо доступу до журналу та фільтрації
- Передача вихідних кодів обробників
- Навчання адміністраторів роботі з журналом
- Підтримка протягом 30 днів після здачі
Швидка перевірка налаштування
Після підключення обробників: змініть тестовий товар в адмінці, потім відкрийте Налаштування → Інструменти → Журнал подій, відфільтруйте за типом IBLOCK_ELEMENT_UPDATE. Запис має містити ID елемента та diff змін в описі.
Налаштування базового логування займає один робочий день. Отримайте консультацію з налаштування логування вже сьогодні. Звертайтеся — ми допоможемо налаштувати логування під будь-які вимоги. Отримайте прозорість та контроль над усіма діями на вашому Бітрікс-проєкті.
Детальніше про журнал подій в офіційній документації Бітрікса: Журнал подій