PS PrestaShop Intermediate

Back-Office Audit Log — Complete guide

Install, configure and operate the back-office audit log: traceability of creations/updates/deletions with before/after diff, login tracking, sensitive-field masking, retention and CSV export for PrestaShop 8 and 9.

Updated Module version 1.0.0

Overview

The Back-Office Audit Log module records who changed what and when in your PrestaShop back office. For every creation, update or deletion, it keeps the employee involved, their profile, the IP address, the controller, the HTTP method, the URL, the timestamp and — for updates — the field-by-field detail (old value → new value). It also logs each employee’s session start and, on PrestaShop 8, failed login attempts and logouts.

The module relies solely on the native ObjectModel hooks and performs no core override. It is compatible with PrestaShop 8 and 9, in single- and multistore, and multilingual.

The log is built for security and GDPR compliance: it provides a reliable audit trail (accountability and traceability of processing) without altering how your store works.

Installation

  1. In the back office, open Modules > Module Manager.
  2. Click Upload a module and drop the module ZIP archive.
  3. Once installation is complete, click Configure.

On installation, the module creates two dedicated tables (the log and the changed-field detail), registers its hooks and adds the Advanced Parameters > Audit Log menu entry. No configuration is required to get started: a relevant set of entities is already enabled by default.

How it works

The module listens to the generic ObjectModel hooks present in PrestaShop 8 and 9 (object add, update and delete) as well as the back-office display hook. On every operation on a monitored entity:

  • it identifies the logged-in employee, their profile and the active store;
  • for an update, it compares the before and after state and records only the fields that actually changed;
  • for a creation or a deletion, it records (optionally) all of the object’s fields;
  • it writes the entry directly to the database.

Writes are done in direct SQL, without going back through ObjectModel: there is therefore no risk of hook recursion, and the audit can never interrupt a business operation.

Configuration

Monitored entities

Tick the entities to track, grouped by domain: Catalog (products, categories, manufacturers, suppliers, combinations, specific prices, images, stock…), Customers & orders (orders, order states, customers, addresses, groups, cart rules), Shipping & localization (carriers, countries, zones, currencies, taxes), Content (CMS pages and categories, metadata) and Administration & security (employees, profiles, webservice keys, shops, configuration).

Only the ticked entities are recorded. A relevant, low-noise set is enabled by default; Configuration is disabled by default because it is very verbose.

Track BO logins

When this option is on, the module records each employee’s session start. On PrestaShop 8, it also records failed login attempts (with the email entered) and logouts.

On PrestaShop 9, the login page is handled by Symfony: successful logins are tracked, but failures and logouts on the login screen are not captured. All data changes remain tracked on both versions.

Keep the detail of creations/deletions

Enables recording of all fields on an add or a delete. Disable this option to keep only the event (who, what, when) without the object’s full detail.

Also track actions outside the back office

By default, only actions performed by an employee logged into the back office are recorded. Enable this option to also track changes triggered in the front office, by a CRON task or via the webservice. The volume of entries may then increase significantly.

Retention

Set the retention period in days (365 by default). An automatic daily purge removes older entries. Set the value to 0 for unlimited storage.

Excluded employees

Enter the employee IDs (comma-separated) whose actions should not be tracked — for example a technical integration account.

Volume limits

Two settings protect the database: the maximum number of fields stored per entry and the maximum length of a value (beyond which the value is truncated). An internal safeguard also limits the number of entries written per request to preserve performance during mass imports.

Viewing the log

Go to Advanced Parameters > Audit Log. The list shows, for each entry: the date, the action type (colored badge), the entity, the object ID and label, the number of changed fields, the employee, the profile, the IP address and the controller. You can filter and sort on these columns.

Detailed view

Click an entry to open its detailed view. It shows the full context (employee, IP, controller, method, URL, User-Agent) and, for an update, a field-by-field diff table: the old value (on a pink background, struck through) and the new one (on a green background).

Sensitive-data security

Sensitive fields are never stored in clear text. Any field whose name contains a sensitive term (password, secure_key, token, API key, webservice key…) is automatically replaced with asterisks. The log records that a sensitive field changed without revealing its value.

Compliance, retention and export

The log keeps the employee’s name even after deletion, guaranteeing a durable audit trail. From the log screen, the Export to CSV button generates a UTF-8 file (Excel-compatible) including every column: date, action, entity, object, employee, profile, IP, controller, method and URL. The Purge button removes all entries (an action reserved for profiles with the delete permission).

The CSV export is ideal for providing your audit evidence to a DPO, an auditor or a security reviewer.

Uninstallation

Uninstalling removes the log tables, the entire history, the hooks and the menu entry. This operation is permanent: remember to export the log beforehand if you need to keep a record of it.

FAQ

Does the module slow down the back office?

The impact is minimal: direct SQL writes, per-entity filtering and a volume safeguard. You can reduce the load further by limiting the monitored entities.

Are passwords stored?

No. Sensitive fields are masked with asterisks before storage.

Does the module modify the PrestaShop core?

No, no override. The module uses only the official ObjectModel hooks and an internal autoloader.

Are front-office actions tracked?

By default no: the log focuses on employee actions in the back office. You can enable tracking of front-office, CRON and webservice actions in the configuration.

Is the module compatible with PrestaShop 9?

Yes, compatible with PrestaShop 8.x and 9.x, in single- and multistore and multilingual.

Was this page helpful?

Still stuck? Contact support