HR Employee Update Requests
Let staff raise their own data change requests and route them through submit, approve and apply on a tamper-evident trail.
Why this module
HR Employee Update Requests
Employees raise their own changes
A new request defaults to the current user's employee and asks for the field, the value on file, the new value and a reason. Staff document the change instead of emailing HR, and the request stays attached to the right employee.
Every step is group-gated
Submit is open to self-service employees, approve and reject sit with HR managers, and apply sits with HR officers. The engine refuses any transition a user's groups do not permit, and refuses any move out of a final applied or rejected state.
Recorded on a tamper-evident trail
Create, edit and state change on each request write rows to an append-only, sha256 hash-chained audit log with before and after values. A verify routine walks the chain and flags the first altered row.
Day in the life
From request to applied in four clear steps
An employee opens Update Requests, picks the field to change, types the new mobile number and a short reason, and clicks Submit. The request takes an auto-generated UPD reference and lands in the manager's queue as Submitted. The manager reviews and Approves, or Rejects with the reason captured in chatter. An HR officer then marks the request Applied once they have updated the employee record. Every transition and edit is written to the hash-chained audit log, so months later anyone can see who requested the change, who approved it and when it was applied.
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 it is terminal. The workflow engine treats the is_final marker as authoritative and refuses any further transition, even one a misconfigured definition might declare from that state.
Transitions are checked against the acting user's groups, not just hidden in the form. A user without the manager group cannot approve and a user without the officer group cannot apply, with admin the only bypass.
The audit log takes a transaction-scoped Postgres advisory lock before appending, so two concurrent writes cannot read the same chain tail and fork the hash chain. The lock releases automatically on commit or rollback.
An edit that does not actually change an audited value writes no audit row. Before and after snapshots are compared per record, so the trail stays free of empty no-op entries.
Each request is owned by a required company that defaults to the active company. A write that would move a request into a company the user is not a member of is rejected, and any audited override is itself logged.
References come from a yearly UPD sequence. If the sequence cannot yield a number the create still completes with a safe fallback reference rather than failing.
What is inside
Built to do the job, end to end.
- One focused request model. eh.hr.employee.update holds the reference, employee, field label, current value, requested value and reason. It owns no workflow or audit code of its own and instead composes the platform mixins.
- Workflow from a definition. The draft, submitted, approved, applied and rejected states and the submit, approve, apply and reject transitions are loaded as data on the workflow engine, so the path and the groups on each step are configurable without code.
- Audited and company-aware mixins. The model inherits the audited mixin and the strict company-aware mixin, giving it the hash-chained trail, before and after capture, required company ownership and cross-company write refusal for free.
- List, form and menu. A list of requests, a form with a statusbar and submit, approve, apply and reject buttons that show only in the right state, mail.thread chatter, and an Update Requests menu under the HR requests section.
- Tested workflow. Bundled tests cover auto-numbering and the draft default, the full submit, approve, apply path, and the reject path from submitted.
Honest about the edges
What this does not do, so nothing surprises you.
- Applying a request moves the workflow to Applied and records the decision; it does not automatically write the requested value onto the employee record. The edit to hr.employee remains a deliberate HR step.
- There is no employee portal or website form in this module. Requests are raised from the Odoo backend by users who have an employee and the self-service group.
- Approval here is a single group-gated manager step. This module's transitions do not route through the multi-step approval engine, so there is no built-in approval ladder or self-approval block on the approve action beyond the group check.
- The module does not validate that the requested value is a real field on the employee or that it is well formed. Field label and values are free text for a human to interpret.
- Requires the EH HR Platform base, compatibility and workflow engine modules. It is not a standalone add-on.
- Built and tested for Odoo 16 Community.
Odoo 16 employee self service, HR change request workflow, employee data update request, HR approval routing Odoo, audited HR records, hash chained audit log, multi company HR Odoo, employee information update, HR self service request form, workflow statusbar Odoo HR
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