EH HR Resignation
Resignation and offboarding, governed end to end.
Why this module
EH HR Resignation
No one is offboarded with assets out
Marking a resignation offboarded is blocked while any exit clearance item is still open. An empty checklist does not block, so the gate is opt-in: generate the standard IT, manager, finance, HR and facilities items when you want the control, or leave it off.
States and rules live as data
The submit, accept, mark offboarded and withdraw steps and the groups allowed to fire each one come from the workflow definition, not hardcoded Python. An administrator adjusts the separation flow without a developer on a billable day.
Every step is provable after the fact
State changes, employee, resignation date, last working day and reason are written to an append-only, SHA-256 hash-chained log you can verify on demand. Show who changed what when an exit is later questioned.
Day in the life
From notice to clean exit, on the record
An employee opens a resignation, picks a reason and a notice period, and submits it. The last working day is suggested as the resignation date plus the notice period, and can be overridden where a contract differs. A manager accepts it, then HR generates the standard exit clearance checklist so IT revokes access, finance settles final pay, and assets and access cards come back. Each item is ticked off with a responsible owner and notes, and the progress bar tracks completion. The record cannot be marked offboarded until every clearance item is done. If the person changes their mind while still submitted, they withdraw it. At every step the workflow records the transition and the audit log captures the change, so the whole separation is reconstructable later.
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.
action_res_complete raises a UserError naming the record while any checklist item is still open, so a half-cleared leaver cannot be marked offboarded; a resignation with no checklist counts as 100 percent complete and passes.
Generate Clearance is a no-op when items already exist, so clicking it twice never duplicates the standard IT, manager, finance, HR and facilities lines.
Offboarded and withdrawn are marked final in the workflow definition, and the engine refuses any further transition out of a final state even if a misconfigured definition declared one.
Audit appends take a transaction-scoped Postgres advisory lock so concurrent transitions on different resignations cannot fork the hash chain, and verify_chain walks it to surface the first broken row.
Each resignation carries a required company and cross-company writes are rejected unless an explicit, separately audited override context is set, closing the null-company leak pattern.
Submit and withdraw are gated to the employee self group while accept and mark offboarded are gated to the HR manager group, and a non-admin outside the transition's groups is refused.
Last working day recomputes whenever the resignation date or notice period changes, yet stays editable so a negotiated final date survives later edits to the notice period.
What is inside
Built to do the job, end to end.
- Resignation record. The eh.hr.resignation model carries employee, resignation date, notice period in days, a computed and overridable last working day, reason type and free-text reason, and the workflow state, with the reference number generated from a yearly RES sequence on save.
- Exit clearance checklist. The eh.hr.resignation.checklist model holds one clearance item each: an area (IT, manager, finance, HR, facilities or other), what needs doing, a responsible person, a done flag and notes, ordered by a drag handle. Mark done and reopen actions drive the gate.
- Workflow on the shared engine. A seeded workflow definition supplies the draft, submitted, accepted, offboarded and withdrawn states and the submit, accept, complete and withdraw transitions, each with its allowed groups. The module owns no state-machine code of its own.
- Audit and company mixins. Inherits the platform audited mixin for the hash-chained log and the strict company-aware mixin for multi-company safety, plus the standard chatter, so tracking and a verifiable trail come from the core platform rather than bespoke code here.
- Views and access. List and form views with a status bar, a clearance progress bar and an inline editable checklist, a Resignations menu, and access rules for the HR admin, manager and self-service groups straight from the manifest.
Honest about the edges
What this does not do, so nothing surprises you.
- Targets Odoo 17 Community and depends on eh_hr_core, eh_hr_compat, eh_hr_engine_workflow and the standard hr module; it is part of the EH HR Platform and is not a standalone install without those.
- This module owns no workflow or audit code of its own; the state machine, the hash-chained audit log and the multi-company guard come from the shared platform engines it depends on.
- It records the resignation, notice period and offboarding flow. It does not compute final pay, settlements or gratuity, and does not archive or deactivate the employee record for you.
- None of this module's own transitions require an approval chain; acceptance and offboarding are gated by user groups, not by a multi-step approval engine.
- The exit clearance gate only applies when a checklist exists; a resignation with no clearance items can be marked offboarded directly.
- Notifications, reminders and policy rules are separate platform modules; this module emits the workflow events but does not bundle those engines.
odoo 17 resignation, employee offboarding odoo, exit clearance checklist, notice period last working day, employee separation workflow, odoo hr resignation module, offboarding audit trail, resignation approval workflow, hr exit interview odoo, multi company hr odoo, self hosted odoo hr, lgpl hr offboarding
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