EH HR Resignation
Resignation and offboarding, governed end to end.
Why this module
EH HR Resignation
A workflow, not a status field
Draft, submitted, accepted, offboarded and withdrawn are real workflow states with group-gated transitions. Employees submit and withdraw their own request, managers accept and mark offboarded, and a final state refuses any further move. The steps come from a data-defined workflow definition, so you adjust who can do what without touching Python.
No one leaves with the laptop
One click seeds a standard exit checklist across IT, manager, finance, HR and facilities, each with a responsible person and notes. Completion is blocked while any item is open, with the progress shown as a bar. An empty checklist is treated as cleared, so the gate only bites when you actually use it.
Audited at every step
State, employee, resignation date, last working day and reason are captured to the platform append-only audit log, where each row carries the sha256 of the row before it. A transaction-scoped Postgres advisory lock serializes appends so concurrent writes never fork the chain, and the log grants read only, never edit or delete.
Day in the life
From notice to a clean exit
An employee files a resignation, picks a reason, and the system suggests the last working day as the resignation date plus the notice period in days, which the manager can override. The employee submits it, the manager accepts it, and an exit clearance checklist is generated across IT, finance, HR and facilities. Each owner clears their item and ticks it off as the progress bar climbs. The manager tries to mark the record offboarded while one item is still open and the action is refused with a clear message. Once the last item is done, completion lands and the record moves to its final offboarded state. Throughout, every transition and field change is written to the hash-chained audit log, so months later an auditor can see exactly who accepted, who cleared what, and when, and prove nothing was edited after the fact.
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 and the state does not move while any clearance item is still open. The block is verified by an automated test that opens a checklist, accepts the request, fails completion, then ticks every item and succeeds.
With no clearance items at all, clearance_complete computes to True (100 percent), so a resignation with no checklist can be completed normally. The gate only engages once you actually generate or add items.
Offboarded and withdrawn are marked is_final in the workflow definition. The engine refuses any further transition out of a final state, even one a misconfigured definition might declare, so a completed exit cannot be silently reopened.
Submit and withdraw are limited to the employee-self group, accept and mark-offboarded to the HR manager group. A user outside a transition's allowed groups gets a permission UserError instead of an unauthorized state change.
Generate Clearance is a no-op when the checklist already has items, so clicking it twice never duplicates the five standard areas. Sequence numbers are seeded in tens so rows stay in a stable, reorderable order.
The audited mixin captures a before snapshot of only the whitelisted fields and emits no audit row when a write changes nothing audited, so the trail stays signal and the hash chain is not padded with empty entries.
Two offboardings completing at the same instant each append to the audit log under a transaction-scoped Postgres advisory lock, so the two rows chain strictly in order and neither forks the hash chain.
Last working day is stored but recomputes from resignation date plus notice period whenever either changes, and stays manually overridable. Changing the notice period from 30 to 14 days reflows the suggested date, as the test asserts.
What is inside
Built to do the job, end to end.
- Resignation record. eh.hr.resignation holds the employee, resignation date, reason type and free-text reason, notice period in days, the suggested last working day, and the workflow state. The reference number is generated from a per-year sequence on save. It inherits the workflow, audited and company-aware platform mixins plus mail.thread for chatter.
- Exit clearance checklist. eh.hr.resignation.checklist is one clearance item per row, with an area (IT, manager, finance, HR, facilities, other), a responsible employee, a done flag, notes and a handle for ordering. Mark-done and reopen actions flip the flag, and the parent rolls the items up into a completion flag and a percentage progress bar.
- Workflow, audit and access. A data-defined workflow definition supplies the five states and four transitions with their group permissions. The five standard clearance areas are seeded by Generate Clearance. Audit capture is scoped to state, employee, dates and reason. Access is a three-tier ladder: admin, manager and employee-self, with unlink reserved to admin.
Honest about the edges
What this does not do, so nothing surprises you.
- This module manages the resignation and offboarding process. It does not compute final pay, settlements or end-of-service amounts. Pair it with your payroll and gratuity modules for the financial side of a leaver.
- Marking a record offboarded does not automatically archive or deactivate the employee, revoke logins, or close attendance and leave. The clearance checklist tracks those tasks for humans to action; it does not perform them.
- The clearance checklist is a list of tasks with owners and a done flag. It does not integrate with the asset custody module to auto-detect returned equipment, and there is no built-in exit-interview form or survey beyond the free-text reason field.
- Notice period is a plain number of calendar days, so the suggested last working day is resignation date plus that many days. It is not aware of weekends, public holidays or working calendars; adjust the suggested date manually where that matters.
- Resignation transitions are direct and group-gated (employee submits, manager accepts), not routed through a multi-step approval chain. The platform approval engine exists but this workflow does not invoke it.
- Offboarding is per record. There is no bulk-complete or mass-offboard action for processing many leavers in one click.
Odoo HR resignation, employee offboarding Odoo, exit clearance checklist, notice period tracking Odoo, last working day, resignation workflow Odoo, HR separation management, employee exit process, Odoo 19 Community HR, offboarding checklist, resignation request Odoo, audited HR workflow, tamper evident audit Odoo, Odoo 16 17 18 19 HR, self-hosted HR Odoo
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