What an Odoo audit trail should actually record
TechnoVision Engineering
Publication date pending · 9 min read
An audit trail exists to answer questions asked months later by someone who was not in the room. Most implementations answer only the easiest of those questions.
What changed is the easy half
Recording that a field moved from one value to another is straightforward, and most systems do it. The harder question at review time is who was in a position to make that change at that moment - which groups they held, which record rules applied, and whether that access was granted for this task or inherited two role changes ago.
An access review without change history is an opinion. With it, it is evidence.
The six things worth recording
- The write itself, with before and after values on the fields you nominated as sensitive.
- The actor, the company scope, the session and the originating address.
- The permission state at the time of the write, not at the time of the query.
- Reads that leave the system: exports, their row counts and the fields included.
- Permission changes themselves, as first-class events with their own history.
- Failed attempts, which are frequently more interesting than successful ones.
Retention is part of the design
Scope before volume
The instinct is to track everything and filter later. In practice a nominated set of models and fields - bank details, prices, credit limits, journal entries, user and group records - produces a log someone will actually read, at a write cost the database will tolerate.
This is the reasoning our own product was built on, which is why Security & Audit Center asks you to choose what is sensitive as its second setup step rather than its last.