Administrator Action Log

What this solution does

On Friday evening, the catalog displays incorrect data: prices are distorted, part of the products has disappeared from the storefront, and users have gained unauthorized permissions. The key question is who made the changes and exactly what was modified. The standard 'Intrusion Log' only records the fact that an element was changed, without revealing details. Restoring from a backup reverts the entire system to yesterday's state, including all actions performed by other staff.

The 'Administrator Action Log' module answers precisely: it identifies the specific user, the exact time, the modified field, and its previous value.

DIFFERENCE 'WAS — IS', NOT 'OBJECT CHANGED'

The event card displays all affected fields: on the left is the original value, on the right is the new value. This applies to name, activity, price, order status, group composition, and setting values. Determining the cause of a broken card takes one minute.

The comparison is performed correctly. The Bitrix system saves objects in parts: the request contains only the fields that were edited. Therefore, the module compares only the incoming fields rather than a full snapshot of the object. Otherwise, editing a single field (such as a name) would appear in the log as eight separate changes, rendering the analysis useless.

REVERT A SINGLE VALUE

A "Restore" button is available next to each change. The system restores a specific field of a specific record, not the entire portal state from yesterday. Rolling back an entire object would erase work performed by other users after the last change. Before restoring, the module checks the current value of the field: if it has been modified again, the system issues a warning instead of silently overwriting the data. The restoration action itself is also logged.

Seven audit areas can be enabled independently. These include: infoblock content (name, activity, text, section, symbolic code); catalog (prices and stock levels, the data most frequently queried to identify who changed a price); orders (status, amounts, cancellation, comments); users; groups and permissions; module settings; and access to the administrative section.

When working with a large catalog, the list of tracked infoblocks is automatically limited to those where history tracking is actually required.

Human actions are separated from machine actions. Each event records its source: the administrative panel, the storefront, 1C exchange, an agent, the console, or REST. By default, exchanges, agents, and console actions are not written to the journal. The event list includes a "people only" filter. Without this filter, a nightly exchange affecting stock levels across the entire catalog would fill the journal with technical entries within a week, making it impossible to locate human actions. An integration account can be excluded from the journal separately.

Secret data does not enter the journal.

The Administrator Action Log (ozhogov.audit) automatically masks sensitive data. If a field name contains pass, token, key, secret, hash, or other words from a configurable list, the value is replaced with dots before being written to the database. This allows the fact of a change to be visible while hiding the actual value. The log is accessible to a broader audience than module settings, so it must not store passwords in plain text.

Notifications for Rare Changes

Access rights, module settings, and user accounts are changed deliberately and infrequently. Any unexpected change here requires immediate investigation rather than deferral until the end of a quarter. The module sends a single summary email for a batch of such events instead of a separate message for each action. This prevents important information from being lost due to a high volume of emails that would occur with frequent notifications.

Log Size Management

The retention period for events is configurable, with critical events stored for twice as long to facilitate incident investigation. Data cleanup is performed in batches by a background agent to avoid locking large tables. Long text descriptions are automatically truncated, as storing full details, such as a product description, in every record is unnecessary.

Access Levels

Three access levels are provided: access denied, log viewing only, and full access with settings and value restoration capabilities. A user with log viewing rights does not need editing permissions for the journal.

Module Limitations

The module does not perform actions beyond the described audit and access control functions.

The module does not replace backup solutions: it records changes to a single field rather than the entire portal state. It does not duplicate the content version control system, which stores full document versions for editors, whereas the action log answers the question of who made the change. The tool does not track storefront visitors, recording only actions by users with editing rights. The module does not modify the core system or replace standard pages.

Version 1.0 Limitations

Functionality is limited to seven areas. Element properties are recorded as field changes, with no separate history maintained for each individual property. Reverting orders and login events is not supported: orders have their own status and payment logic, while login is an event rather than a state. This version does not support exporting the log to a file.

System Requirements

— 1C-Bitrix: Site Management or Boxed Bitrix24, main module version 20.0.0 or newer;

— PHP version 8.2 or newer;

— MySQL 5.7+ / MariaDB 10.3+ or PostgreSQL (for PostgreSQL, main module version 23.900.900 or newer is required);

— Modules "Information Blocks", "Trade Catalog", and "Online Store" are optional: without them, the corresponding areas are not included;

— Active agents (cron execution is recommended): these handle log cleanup and notification sending.

If “Administrator Action Log” is required, General iT can help with installation, configuration and a technical check after integration.