Employee History Log
A tamper-evident timeline of every employee milestone, company-scoped and written straight to the platform audit chain.
Why this module
Employee History Log
Every change leaves a trace
Creating, editing, or deleting a history entry writes a row to the platform audit log. That log is append-only and sha256 hash-chained, so a tamper of any past row is detectable by walking the chain. The history record and the record of changes to it are both preserved.
Records belong to a company
Each entry requires a company and defaults to the active one. Writing a record into a company the user does not belong to is refused unless an explicit, audited override is set. Null-company leakage across companies is not possible here.
A log, not a workflow
This module owns no approval ladder, no automation, and no audit code of its own. It is a flat, manually authored history that leans on the platform's audited and company-aware mixins. What you see captured is exactly what is stored and audited.
Day in the life
Reconstruct any career, on demand
A payroll query lands: when did this person move from Developer to Team Lead, and what was the old title? Open the employee, read the timeline newest-first, and there it is: event date, promoted, old value Developer, new value Team Lead, with the annual-review note attached. If anyone asks whether that row was edited after the fact, the platform audit chain answers it. Officers and admins maintain the log; self-service users can read their own without write access.
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.
The audit log behind each entry is append-only and hash-chained. Each row stores the sha256 of the previous row plus its own fields, so verify_chain() detects any edit that did not recompute the entire downstream chain.
Audit appends are serialized by a transaction-scoped Postgres advisory lock, so two concurrent writes cannot read the same chain tail and fork it. The lock releases automatically on commit or rollback.
company_id is required and defaults to the active company. A cross-company write is rejected with an AccessError unless the allow_cross_company context is set, and that elevation is itself written to the audit log with every affected record id.
A write that does not actually change any captured field emits no audit event. Before and after snapshots are compared per record, so the audit trail is not polluted with empty edits.
Deleting an entry still records an unlink event with the display name before removal, and the row stays cascade-linked to its employee so orphan history cannot accumulate.
What is inside
Built to do the job, end to end.
- The history model. eh.hr.employee.history with title, employee, event date, event type (six values), description, and old value plus new value. Ordered newest first by event date, indexed on employee and date for fast lookup.
- Audited and company-aware mixins. Inherits the platform audited mixin and the strict company-aware mixin from eh_hr_core. It declares which fields to capture and otherwise owns no audit or scoping logic of its own.
- Views and navigation. List, form, and search views with filters for joined and left events and group-by employee or event type. The form carries a chatter thread. The menu sits under the platform records section, gated to HR officers.
- Access control. Three access rules: HR admins and officers get full read and write, self-service employees get read-only. No public or portal exposure.
- Tests. A post-install test suite covers field capture, the joined default and today's date default, and newest-first ordering across an old and a future-dated entry.
Honest about the edges
What this does not do, so nothing surprises you.
- This is a manual log. It does not automatically detect promotions, transfers, or salary changes from contract or employee records; entries are authored by HR.
- There is no approval workflow, escalation ladder, or self-approval guard on history entries. Officers and admins write directly.
- The hash-chained audit log, advisory lock, and verify_chain integrity check live in eh_hr_core, not in this module. This module consumes that machinery rather than implementing it.
- It depends on eh_hr_core and eh_hr_compat and is not a standalone install. It is part of the EH HR Platform.
- No reporting, dashboard, or printable PDF certificate of service is included; the data is presented through standard list and form views.
odoo 17 employee history, employee change log odoo, hr milestone tracking, promotion transfer history odoo, salary change history, role change log, employee timeline odoo community, audited hr records, multi company hr odoo, hr audit trail, before and after value tracking, erp heritage hr platform
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