Who changed the price? Audit trails for Magento Open Source
Adobe Commerce answers "who changed this" with its built-in Action Logs; Magento Open Source ships nothing comparable. Admin Activity Log records every admin change with a field-level before/after diff, plus login attempts and live session control.
ExtensionA product goes out of stock that nobody disabled. A shipping method starts charging the wrong rate on a Tuesday. A price is twenty per cent off and the person who set it left in March. In a store with one administrator these are puzzles; in a store with four, an agency and an ERP integration, they are a weekly tax on everyone's attention – because the platform keeps no record of who did what.
Adobe Commerce answers this with its built-in Action Logs. Magento Open Source ships nothing comparable, and the gap is not small: the admin panel writes to the catalogue, to customers, to orders and to configuration, and none of those writes leaves a trace that names a person.
What it is for
Admin Activity Log, an extension for Adobe Commerce and Magento Open Source,
records every change an administrator makes, with the old and the new value of
each field that actually moved. Not "product 2045 was saved" – price
10.00 → 8.50, name before and after, status enabled to disabled, each on
its own row, with the person, the role, the time, the IP and the channel the
change arrived through.
What changes in the week is the shape of the question. "Who dropped this price" stops being a thread in Slack and becomes a filter on a grid. A setting that broke checkout on Tuesday has a record showing what it was on Monday. And when an integration writes something nobody remembers approving, the record names the channel, so the conversation starts with the system rather than with a colleague.
How it can be used
As an audit trail across a team. The common case: several people with admin access, some of them external. Every change is attributed, and five separate ACL resources mean the log itself follows the same discipline – viewing the action log, viewing login attempts, viewing sessions, terminating them and editing the settings are five grants, not one. A support contractor can be given the log to read without being given the power to end other people's sessions.
As a configuration record. Payment, shipping and tax settings are the changes that cost money when they go wrong and are hardest to reconstruct, because Magento saves a whole section at once. This extension records one before/after pair per setting that actually changed, names the website or store view when the value was saved at that scope, and stores credentials masked – the log shows that an API key changed, never what it was.
As the record's own history. The journal is also where the record is: a Change History section on the product, customer, category, CMS page and CMS block forms, a tab on the order view that lists the order's invoices, shipments and credit memos beside the order's own changes, and a tab on the admin user form with both axes of one administrator's history – what was done to that account, and what that account did everywhere else. Each entry opens the full diff, which names the store view the change belongs to and leads back to the record it came from.
As a security surface. Login attempts, successful and failed, with IP, user agent and the reason a failure failed. Live admin sessions in a grid, with force-termination. Neither is exotic, and both are missing from a stock Open Source install.
As a data-retention policy that runs itself. A configurable period and a daily purge. The trade-off is stated rather than hidden: a journal you keep forever is a liability, so the default is ninety days and the number is yours to set.
As an integration point. One event is dispatched when a record is written. If you want an email when someone edits a payment method, that is your code's to send – the extension does not try to be a notification system.
How it compares
The category is real and priced across a wide band. Measured on 2026-08-27 by reading the structured data and breadcrumbs on the Adobe Commerce Marketplace listings themselves: comparable admin-logging extensions cluster under Site Optimization → Site Monitoring, with the cheapest two filed under Content & Customizations instead. Seven sell a one-time licence, from about 50 to 179 US dollars. Two bill by subscription – the category's most established listing at 289 dollars a year, another at 149. Two more are free.
Against that spread, this extension is 99.99 US dollars, once. It sits at the entry of the one-time cluster whose members also ship a field-level diff, login attempts, sessions and retention – measured feature by feature on 2026-08-31 – and costs less than four months of the subscription leader. What the dearer members of that cluster add is one-click revert, page-visit history and e-mail alerts; what this one adds instead is below.
A subscription buys something a one-time licence does not, and it is fair to say so: continuing releases and vendor support for as long as you pay. If that is what you want from a supplier, the annual listings are the honest choice. The free listings are equally honest for a store that needs a basic record and nothing else.
What this extension offers against both is a narrower promise kept precisely:
The diff is field-level and it is real. Not a note that an entity was
saved, but the fields that changed, old beside new, with system noise and
unchanged fields filtered out rather than dumped. A save made in one store
view reports the fields the person edited and not the ones the store keeps
inheriting; a price that reads 10.000000 in the database and 10.00 on the
form is one value, not a change; and Magento's own housekeeping – the
permission refresh it saves on a user's next request after a role change – is
not attributed to that user as an edit they never made.
The admin REST API is on the same journal. Changes made with an admin token – by an ERP, a PIM, a middleware sync – appear in the same grid with the channel named. Integration and customer tokens are deliberately ignored, so the journal records administrators rather than traffic.
It is read-only by design, and that is a feature. The extension writes to its own three tables and, on request, ends an admin session. It does not write to your catalogue, your customers, your orders or your configuration. An audit tool that can also modify the things it audits is a larger surface than the problem requires.
Credentials are masked at write time. Six patterns that cannot be switched off, plus any you add. The masking happens before the value is read into the diff, so the plaintext is never stored and then hidden – it is never stored.
Everything above is checkable in the shipped module before you trust it, which is the only kind of comparison worth making.
What it does not try to be
It does not restore anything: the one-click rollback this extension used to have was removed in 0.2.0, deliberately, and the reasoning is in the FAQ. It does not log the command line, cron or data imports. It does not watch the storefront. If any of those is the requirement, this is not the extension – and the FAQ says so before you buy rather than after.