Employee History Log
A tamper-evident, company-scoped record of every employee milestone and change.
Why this module
Employee History Log
Every change is provable
Each history row you create, edit, or delete is written automatically to the platform append-only, SHA-256 hash-chained audit log. Nothing is captured in the module itself, so the trail cannot be quietly rewritten from here.
Strict company isolation
Every entry carries a required company, defaulting to the active company. Moving a record into a company the user does not belong to is refused, and any permitted cross-company change is itself recorded in the audit log.
Before and after, in plain words
Each milestone keeps the old value, the new value, and a short description, so a promotion or salary change reads as a clear story rather than a guess reconstructed from other tables.
Day in the life
A promotion, recorded once and kept honest
An officer opens Employee History, picks the employee, sets the event type to Promoted, and records the old role as Developer, the new role as Team Lead, and a one-line note pointing at the annual review. The entry dates itself to today, attaches to the active company, and shows a chatter thread on the form. Behind the scenes the create is appended to the hash-chained audit log. Months later, anyone reviewing the employee can scan a single date-ordered timeline of joins, transfers, salary changes, role changes, and departures, filter to just Joined or Left, or group by event type, with full confidence that no row was edited or removed without leaving a trace.
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.
Create, write, and unlink each emit an audit row. The log is append-only and hash-chained, so editing or deleting a history entry is recorded and any later tampering is caught by the platform chain verification.
Audit appends are serialized by a Postgres transaction-scoped advisory lock, so two officers saving entries at the same time cannot fork or corrupt the hash chain. The lock releases automatically on commit or rollback.
Company is required and defaults to the active company. Writing a record into a company the user is not a member of is refused with an access error, and a permitted cross-company change is logged with the affected record ids.
A write that does not actually change any captured field emits no audit noise. Only real before-and-after differences across the seven business fields are recorded.
History entries are linked to the employee with cascade delete, so removing an employee removes their history rows, and each of those deletions is captured in the audit trail.
Self-service employees get read-only access. Only HR officers and admins can create, edit, or delete history entries, and the menu itself is restricted to officers.
What is inside
Built to do the job, end to end.
- The history model. A single eh.hr.employee.history record with a required title, a required employee, a dated event, an event type (joined, promoted, transferred, salary change, role change, left), an old value, a new value, and a free-text description. Entries default to today and sort newest first.
- Platform mixins, not bespoke plumbing. The model inherits the platform audited mixin and the strict company-aware mixin, plus mail.thread for a chatter on the form. The audit and company-isolation behaviour is shared platform code, not re-implemented here, so it stays consistent with the rest of the suite.
- Views and navigation. A date-ordered list, a clean two-column form with a description block and chatter, and a search view with Joined and Left filters plus group-by Employee and group-by Event type. The menu sits under the HR records section for officers.
- Security model. Access rules grant HR admins and officers full create, read, edit, and delete, while self-service employees are limited to read. Captured fields fed to the audit log are declared explicitly on the model.
Honest about the edges
What this does not do, so nothing surprises you.
- Entries are recorded manually. The module does not auto-populate history from contract, job, or salary changes elsewhere in HR.
- There is no approval or escalation workflow. A history row is a flat, audited record with no states.
- Old value and new value are free-text fields, not links to the underlying job, department, or salary records.
- Reporting is limited to the list view with filtering and grouping. There is no dashboard, chart, or scheduled report.
- The audit log, hash chain, and company-scope enforcement live in the platform core modules. This module requires eh_hr_core and eh_hr_compat and contributes the history records, not the audit engine.
employee history log, HR change history, employee milestone tracking, promotion log, transfer history, salary change record, role change history, audited HR records, hash-chained audit trail, multi-company HR, Odoo 19 HR, employee timeline, HR officer records, EH 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