EH HR Employee History
A clean, audited timeline of every employee milestone, kept inside Odoo.
Why this module
EH HR Employee History
Every entry lands in a hash-chained log
Create, edit and delete on a history entry write to an append-only audit log where each row is sha256-linked to the one before it. Run the chain verification on demand to prove nothing was altered after the fact. The history module owns no audit code of its own, it stands on the shared platform engine.
Strict company scoping, no leaks
Each entry is owned by a company and that ownership is required, not optional. Writing an entry into a company the user is not a member of is refused, even under sudo, unless an explicit override is set and itself written to the audit log. No null-company records quietly visible everywhere.
One job, done inside Odoo
A focused log that replaces the side spreadsheet or separate tool. It installs from the Apps menu, pulls only its dependencies, and behaves like the modules beside it from day one. No build to commission, no integration to keep alive.
Day in the life
From annual review to a record that holds up
An employee is promoted at their annual review. An HR officer opens Employee History, picks the employee, sets the event type to Promoted, dates it, and types the old title and new title with a short note on why. The entry saves with the company stamped on automatically and a row written to the hash-chained audit log. Months later an auditor asks who recorded the change and whether it was edited since. The chatter on the entry shows the conversation, the audit log shows the create event with the before and after values, and verifying the chain confirms the row was never touched after it was written. Self-service users can read the timeline but cannot change it.
Edge cases
The cases most modules quietly ignore.
In the shipped code today, each one a place where a cheaper module silently does the wrong thing.
Two entries saved at the same moment cannot fork the audit chain. Each append takes a Postgres transaction-scoped advisory lock, so chain rows are written in strict order and the lock releases on commit or rollback.
Re-saving an entry without changing any captured field writes no audit row. The mixin compares the before and after of the audited fields and skips emission when they match, so the log stays signal, not noise.
There is no approval workflow to game. A history entry is a flat, audited record, so the integrity story is the audit chain and company scoping, not a state machine. The listing does not pretend otherwise.
Moving an entry to another company is refused by default, even for a sudo caller. It succeeds only with an explicit allow-cross-company context, and that elevation is itself written to the audit log with every affected record id.
Entries are linked to the employee with ondelete cascade, so removing an employee removes their history rows, and each removal still emits an unlink event into the audit log before the row is gone.
The owning-company field on audit rows is deliberately outside the hash material, so introducing it never invalidates pre-existing rows and the chain stays verifiable across the upgrade that adds it.
What is inside
Built to do the job, end to end.
- One model: eh.hr.employee.history. A single record type with a title, the employee, an event date defaulting to today, an event type, a description, and an old value and new value. Ordered newest first. No parallel copy of standard HR data.
- Six event types. Joined, Promoted, Transferred, Salary change, Role change and Left, with Joined as the default. Search ships with quick filters for Joined and Left and group-by on employee and event type.
- Audited and company-scoped by inheritance. The model inherits the platform audited mixin and the strict company-aware mixin, plus mail.thread for chatter. The seven captured fields are whitelisted explicitly, so the audit log records exactly what matters.
- Role-based access, self-service read-only. HR admins and officers get full create, read, write and delete. Self-service employees get read-only. The menu sits under Records and Compliance and is officer-gated.
- Tested behaviour. Ships with automated tests covering field capture and the automatic company stamp, the Joined and today defaults, and the newest-first ordering.
Honest about the edges
What this does not do, so nothing surprises you.
- This is a manual log, not automatic capture. Entries are created by HR, the module does not watch contracts or job positions and write history rows for you.
- It does not project into the standard hr.* records. Entries live in their own table linked to the employee, they do not rewrite the employee form or contract.
- There is no approval workflow, escalation ladder or state machine on a history entry. It is a flat, audited record by design.
- The audit log and company-scope engines live in eh_hr_core, which this module depends on. Installing this module alone still pulls eh_hr_core and eh_hr_compat.
- Old value and new value are free-text fields. They hold whatever you type, the module does not validate them against the linked record.
employee history odoo, hr change log, employee timeline, employee milestone tracking, career history odoo, promotion history, salary change log, audited hr records, hr audit trail odoo, before and after values, multi-company hr, odoo 18 hr, employee record keeping, transfer history, hr compliance log
Need this fitted to the way you work?
ERP Heritage delivers end to end Odoo work: Odoo Implementation, Customization and Development, Integration, Migration, Consultation, Support and Training. We help teams put this module into production, shape it to their process, and keep it running.
We work with businesses across Australia (Melbourne, Sydney, Brisbane, Perth, Adelaide, Canberra) and the Middle East (Dubai, Abu Dhabi, Riyadh, Jeddah, Doha, Kuwait City, Muscat). Start a conversation at erpheritage.com.au or email info@erpheritage.com.au.
Languages
Available in 19 languages
The interface ships translated out of the box. Switch language in Odoo and the fields, menus, and messages follow.
Please log in to comment on this module