HR Employee Update Requests
Let employees raise a change request for their own details and route it through submit, approve and apply with a tamper-evident trail.
Why this module
HR Employee Update Requests
HR stays in the loop
A request never silently rewrites the employee card. Submit, approve and apply are separate steps, each restricted to a different group, so the change someone asks for is reviewed before anyone acts on it.
Every change is provable
Each create, edit and transition is written to an append-only audit log whose rows are sha256 hash chained. A single integrity check walks the chain and flags the first row that was tampered with.
Built on the HR Platform
The workflow, audit and company rules come from the shared EH HR Platform engine, not from this module. You get the same behaviour and the same trail as every other request type in the suite.
Day in the life
An address change, start to finish
An employee opens a new update request, picks the field to change, types the current and requested values and a short reason, then clicks Submit. The request gets a reference like UPD/2026/00042 and moves to Submitted. Their manager reviews it and clicks Approve, or Reject if the detail looks wrong. An HR officer then clicks Apply once the underlying record has been updated, closing the request at Applied. Every one of those steps is stamped into the audit log with who did it and when.
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.
Once a request reaches Applied or Rejected the workflow treats it as final and refuses any further transition, even one a misconfigured definition might declare from it.
Each transition checks the user against its allowed groups. A self-service user can submit but cannot approve or apply, and the mixin raises a clear error rather than silently advancing.
The audit chain takes a transaction-scoped Postgres advisory lock before appending, so two concurrent writes cannot read the same tail and fork the chain.
verify_chain walks the log in keyset-paginated batches and returns the id of the first row whose recomputed hash no longer matches, giving a cheap tamper check independent of chatter.
Company is required and defaults to the active company. A write that moves a record to a company the user does not belong to is refused, and any permitted cross-company elevation is itself written to the audit log.
A write that does not actually change a captured field produces no audit row, so the trail records real changes only and stays free of empty noise.
What is inside
Built to do the job, end to end.
- Request model. eh.hr.employee.update holds the employee, the field label, current and requested values and a reason. Names are generated from a company-independent sequence as UPD/YYYY plus a five digit counter.
- Configurable workflow. Draft, submitted, approved, applied and rejected are data records on the workflow engine, with the submit, approve, apply and reject transitions and their allowed groups, so the steps can be retuned without code.
- Audited mixin. State, employee, field label, current value, requested value and reason are captured on create, write and unlink into the hash-chained eh.hr.audit.log.
- Company-aware mixin. Adds the required company field, defaults it to the active company and refuses unaudited cross-company writes.
- Views and chatter. A list and a form with a status bar and step buttons that appear only in the right state, plus a chatter that tracks the employee, field and value fields.
- Tests. Bundled tests cover default reference and initial state, the full submit to apply path and a reject from submitted.
Honest about the edges
What this does not do, so nothing surprises you.
- This module records and routes the request. It does not automatically write the requested value back onto the employee record. Applying the change to the employee card is a manual step performed by HR.
- There is no employee or web portal form in this module. Requests are raised from the standard Odoo backend by users who have an HR self-service group.
- Approval here is a single manager step gated by group. This module does not configure the multi-step approval chains or self-approval guards that the platform approval engine can provide for other request types.
- The audit log, workflow engine and company rules are provided by the EH HR Platform dependencies. This module owns no workflow or audit code of its own and requires those modules to be installed.
- Built and tested for Odoo 17 Community. Other Odoo versions are not covered by this package.
Odoo 17 employee self service, Odoo HR change request, employee data update workflow, HR approval workflow Odoo, Odoo employee information update, hash chained audit log Odoo, multi company HR Odoo, Odoo employee record change management, HR self service Odoo Community, 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