EH HR Lawsuit
Legal case and lawsuit tracking for HR, on the audited platform workflow engine.
Why this module
EH HR Lawsuit
Built on shared platform engines
The module adds one model and a five-state workflow definition. The state machine, the audit trail and the company scoping all come from engines the rest of the HR suite already runs, so a lawsuit record behaves exactly like every other governed document in the platform.
Every change is on the record
Create, edit, state change and delete are written to an append-only, hash-chained log. Each row hashes the row before it, so any after-the-fact edit breaks the chain and is caught by an on-demand verify. You can show who changed a case, when, and from what to what.
Workflow is data, not Python
The five states and four transitions are records in the workflow definition, each transition gated to the HR Officer group. The path and who may advance it are configured, not coded, and final states are marked terminal so a closed or dismissed case cannot be silently reopened.
Day in the life
From filing to closure, on the record
An officer opens a new case, picks the type as labour, names the court and records the amount claimed. Saving assigns a LAW/2026/ reference automatically and the case sits in Draft. Open Case moves it to Open; from there it goes To Court, then Close once the matter is settled, or Dismiss straight from Open if it falls away. Each step is gated to the HR Officer group, written to the chatter, and captured in the audit log with the field-level before and after, so months later the full history of the case reads back without anyone having kept a side spreadsheet.
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.
Closed and Dismissed are marked final in the workflow definition. The engine refuses any further transition out of a final state, even one a misconfigured definition declares, so a resolved case cannot be quietly reopened.
The hash chain is serial by nature. Every audit append takes a transaction-scoped Postgres advisory lock, so two cases changed at the same moment cannot fork the chain; the lock releases automatically on commit or rollback.
Each audit row stores the sha256 of the previous row plus its own fields. verify_chain walks the log with keyset pagination and returns the first broken row, so an edit made directly in the database does not pass unnoticed.
The company-aware mixin requires a company on every case and refuses a write that moves a record into a company the user does not belong to, even under sudo, unless an explicit audited override context is set. The elevation itself is written to the audit log.
The LAW/year reference is drawn from a no-update sequence at create time. If the sequence is missing the create still succeeds with a LAW/AUTO fallback rather than failing, and existing references are never renumbered on upgrade.
The employee link is optional, so a case with no named employee is valid, and where one is set the link is ondelete restrict, so an employee tied to a case cannot be deleted out from under it.
The underlying workflow engine captures the real submitter before any sudo on gated transitions, so a user who fires an approval-gated step cannot later approve their own request even while holding an approver group. The lawsuit workflow ships without approval gating, but inherits this protection if a transition is configured to require it.
What is inside
Built to do the job, end to end.
- Models this module adds. One model, eh.hr.lawsuit, carrying title, optional employee, case type (labour, civil, criminal, other), court, filed date, amount claimed and a free-text description, plus the platform state, company and audit behaviour it inherits.
- Workflow it installs. A Lawsuit workflow definition with five states (Draft, Open, In Court, Closed, Dismissed) and four transitions (Open Case, To Court, Close, Dismiss), each restricted to the HR Officer group, with Closed and Dismissed marked final.
- Sequence and numbering. A company-independent ir.sequence with code eh.hr.lawsuit and prefix LAW/year/, five-digit padded, assigned automatically when a case is created and left untouched on copy.
- Views, menu and security. List and form views with a workflow statusbar and transition buttons, a Lawsuits menu under HR records, and access rules granting HR Admin full control while HR Officer and HR Manager can read, write and create but not delete.
- Audit capture. State, title, employee, case type, court, filed date and amount claimed are the audited fields, captured as before and after snapshots on every write and as create and delete rows in the shared hash-chained log.
- Tests. An automated suite covers default reference and Draft state, the case with no employee, the full Draft to Closed path, and the Dismiss-from-Open path.
Honest about the edges
What this does not do, so nothing surprises you.
- This is a structured case register and workflow, not a legal practice or document management system. It tracks the case record, its type, court, amount claimed and state, not legal documents, billing, hearings calendars or counsel.
- The amount claimed is a single plain monetary figure with no currency field and no settlement, recovery or accounting posting; it is not linked to invoices or payroll.
- The shipped lawsuit workflow advances on HR Officer authority alone and does not require an approval chain. The engine supports approval-gated transitions, but this module does not configure one out of the box.
- Workflow transitions are gated by user group, not by the employee the case is about; there is no separate confidentiality or restricted-access layer on individual sensitive cases beyond the HR Officer group and per-company scoping.
- It targets Odoo 16 Community and depends on eh_hr_core, eh_hr_compat, eh_hr_engine_workflow and the standard hr module, which must be installed.
Odoo 16 HR lawsuit tracking, legal case management Odoo, employee litigation register, labour dispute tracker Odoo, HR legal case workflow, court case management HR, tamper-evident audit trail Odoo, employment claim tracking, multi-company HR case log, Odoo Community 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.
Modules teams pair with this one.
Premium ERP Heritage modules that extend the same stack, each built to the same engineering bar.
A dependency free asynchronous job queue that runs long running and fan out work out of band of the request that...
Post Irish payslips to the general ledger on the Irish chart of accounts
Interactive drag and drop Gantt planner for Odoo 16 Community project tasks with a deterministic server side sche...
Employment Hero Connector is the integration core of the ERP Heritage Employment Hero suite, providing per compan...
The United Kingdom country pack for the ERP Heritage Employment Hero integration
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Employees (hr)
• Discuss (mail) |
| Community Apps Dependencies | Show |
| Lines of code | 1346 |
| Technical Name |
eh_hr_lawsuit |
| License | LGPL-3 |
| Website | https://www.erpheritage.com.au/ |
Please log in to comment on this module