Setting up 1C-Bitrix user activity logging

Setting up user action logging in 1C-Bitrix

When there are 200+ content managers and admins on a site, the question "who changed the product price yesterday at 17:30" has no answer without logging. Stock Bitrix event journal records far from everything, and what it does record — stores without convenient filtering. Task — set up comprehensive logging: who, when, what did, what values changed before and after.

Stock tools: "Event Journal" module

Bitrix out of the box writes events to b_event_log table. Enabled in settings: Settings → Product settings → Module settings → Main module → "Event Journal" tab.

What logs by default:

• Login / logout (USER_LOGIN, USER_LOGOUT)
• Login errors (USER_LOGIN_FAILED)
• Module settings changes (MODULE_RIGHTS_CHANGED)
• File actions via file manager (FILE_DELETE, FILE_EDIT)
• User operations (USER_ADD, USER_EDIT, USER_DELETE)

What's NOT logged:

• Iblock element changes (products, articles, news)
• Order changes (status change, editing)
• Price and stock changes
• CRM module actions (if available)

These are exactly the actions that usually need tracking.

Extending logging via event handlers

To log iblock changes, subscribe to iblock module events:

• OnBeforeIBlockElementUpdate — get data BEFORE change
• OnAfterIBlockElementUpdate — record change fact

Pair of events needed for diff recording — which fields changed and from which values to which. Handler registered in /local/php_interface/init.php via AddEventHandler() or in module events.php file.

Key fields for logging element changes:

For recording use 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),
]);

Records go to same b_event_log table and visible in stock event journal interface.

Logging order actions

The sale module has own events: OnSaleOrderSaved, OnSaleStatusOrder, OnSalePayOrder. For full order audit subscribe to OnSaleOrderSaved — fires on any order save.

Inside handler, \Bitrix\Sale\Order object is available, from which we get current state. For comparison with previous — load order from DB before save (in OnBeforeSaleOrderSaved).

Rotation and storage

Table b_event_log grows fast. On active store (1000+ orders/day, 50+ editors) — up to 100,000 records per month. Rotation settings:

• Retention time — set in event journal settings (by default unlimited)
• Manual cleanup — CEventLog::CleanUp($days) via agent
• Recommendation — keep 90 days in Bitrix, archive old records to separate table or file

Quick setup verification

After connecting handlers: change test product in admin, then open Settings → Tools → Event Journal, filter by IBLOCK_ELEMENT_UPDATE type. Record should contain element ID and diff of changes in description.

Basic logging setup takes one working day. Includes writing handlers for iblocks and orders, testing on test data and rotation setup.