Admin Activity Audit Log

When more than one person has admin access, the question "who changed this price, disabled this product, or edited that setting – and when" has no answer in Magento Open Source. Adobe Commerce ships Action Logs for exactly this; Open Source ships nothing comparable, so the answer is usually reconstructed from memory, from Slack, or not at all.

Admin Activity Log records every change an administrator makes, with the old and the new value of each field that moved. The reconstruction stops being a conversation and becomes a grid you can filter, open and export.

• More than one administrator. Two people and a shared login are enough for the question to come up; an agency, a contractor or a seasonal hire makes it routine.
• Integrations write to your store. Anything using an admin token – an ERP, a PIM, a middleware sync – is logged through the same journal as the admin panel, with the channel recorded, so a change nobody remembers making can be traced to the system that made it.
• Configuration is the part you cannot afford to guess about. Payment, shipping and tax settings are recorded one before/after pair per setting, and credentials are recorded masked.
• You have a data-retention policy. A configurable period and a daily purge keep the journal inside it without anyone remembering to clean up.

• You need to undo changes, not see them. This extension does not restore anything – see the last question. If reverting a bad edit in one click is the requirement, buy an extension built around that, not this one.
• You are the only administrator. A journal of your own actions is a filing cabinet for one person; the value here is attribution.
• The changes you care about come from the command line, cron or an import feed. Those paths are not covered in this version.
• You are on Adobe Commerce and already use Action Logs. The platform covers this; you would be paying twice. The extension installs on Adobe Commerce and works there, but it earns its price on Open Source.

• An Action Log grid of every recorded change: date, user, role, action, entity type and id, the channel it came through, and the IP. Filterable on each of those, and exportable.
• A field-level diff on every record – old value beside new, for each field that actually changed. A save made in one store view reports only the fields the person edited, not the ones the store keeps inheriting, and a value that merely changed its spelling (10.000000 against 10.00) is not a change. The record names the store view the change belongs to – All Store Views, one store view by name, or "not store-scoped" for records without a store dimension.
• Configuration auditing – one before/after pair per setting, with the scope named when a value is saved at website or store-view level.
• Order documents – invoices, shipments and credit memos are logged as they are issued: who issued the document, from the admin panel or over the REST API, and every value it was created with.
• Change History where you work – on the product, customer, category, CMS page and CMS block edit forms, a tab on the order view that lists the order's documents beside its own changes, and a tab on the admin user form with two sections: what was changed on that account and by whom, and what that administrator changed everywhere else. Each entry links to the full diff, and the diff offers a button back to the record it was opened from.
• Login Attempts – successful and failed admin logins with IP, user agent and the reason a failure failed.
• Active Sessions – every live admin session, with force-termination.
• Credential masking – six built-in patterns (password, secret, api_key, private_key, access_token, rp_token) that cannot be switched off, plus any pattern you add. Masked values are stored masked, not hidden at display time.
• Retention – a daily cron purge with a configurable period.
• Five ACL resources, so viewing the log, viewing logins, viewing sessions, terminating them and editing the settings are five separate grants.
• One integration event, so your own code can send an email or a Slack message when something is recorded.

• It does not roll back or restore anything. This extension had one-click restore and removed it in 0.2.0. A restore could not tell whether the record had been changed again since, and fields written by the system rather than by the admin form never enter the journal, so it restored part of a record while appearing to restore all of it. The extension is read-only by design: it writes to its own three tables and, on request, ends an admin session. Nothing else.
• It does not log the command line, cron jobs or data imports. Only the admin panel and the admin REST API.
• It does not log integration or customer tokens – only admin tokens, by design, so an integration's own traffic does not drown the journal.
• It does not watch the storefront. Customer behaviour, orders placed and front-end activity are outside its scope.
• It does not record page visits. It records changes; which admin pages someone opened without changing anything is not in the journal, so the journal stays readable.
• It does not send alerts by itself. It dispatches one event; the message is your code's to send.
• It needs the config cache type enabled – as production always has it – for configuration changes to be recorded. With that cache off, the previous value is read from the database inside the save itself and the change looks like no change.