EH HR Workflow Engine
State machines as data, not Python.
Why this module
EH HR Workflow Engine
Workflows are data, not deploys
States, transitions, allowed groups, approval gates and post-actions all live in eh.hr.workflow.definition records. Adding or rewiring a step is a configuration change an administrator makes, not a Python change that ships on a release.
One engine, every HR module
Instead of each feature re-coding the same draft to submit to approve to done logic, every workflow record composes a single mixin. The statusbar, the transition guard and the audit trail behave identically across the platform.
Gated moves and a real audit trail
Transitions can require a named user group or open an approval chain, and the submitter is captured before any sudo so they cannot approve their own request. Each transition is emitted to the hash-chained platform audit log.
Day in the life
A correction request, end to end
An employee opens an attendance correction. The form already shows the initial state from the workflow definition, so the submit button is live on a brand new record. They submit; the engine advances the state, writes the move to the audit log, and because the transition is marked as requiring approval, opens a chain through the approval engine with the real submitter recorded. A team lead who is not the submitter approves; the engine fires the matching approve transition and the record moves to its final state. From there the final-state guard refuses any further move, even one a misconfigured definition might declare. None of this required a code change: the states, the gate and the approver group were all set up as data.
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.
States flagged is_final are authoritative terminal markers. action_transition refuses any move out of a final state, even one a misconfigured definition declares from it, so records cannot be re-opened by accident.
action_transition accepts the transition code positionally (server callers, named wrappers) or from the context key transition_code (view header buttons, which cannot pass positional arguments), and raises cleanly when no code is resolved.
When a gated transition opens an approval request, the real submitter is captured with submitted_by before the engine runs under sudo, so a user who fired the transition cannot later approve their own request even if they hold an approver group.
The state write is unconditional and the approval gate is a side effect on the follow-up transition, fixing an earlier defect where gated records appeared stuck in their pre-submit state and re-fired duplicate approval requests against the same record.
Transitions with group_ids only execute for users in an allowed group, with an explicit admin bypass via is_admin, and raise a clear UserError otherwise. Empty group_ids means any owner may execute the move.
A database constraint enforces one active definition per code (unique(code, active)), declared through models.Constraint on Odoo 19 and the legacy _sql_constraints list on 16 to 18 so the rule holds on every series.
A model that declares no _workflow_code still keeps a valid state field: the selection resolves to an empty list and the default falls back to False rather than raising, so the mixin is safe to inherit before a definition exists.
What is inside
Built to do the job, end to end.
- Models this module adds. eh.hr.workflow.definition, eh.hr.workflow.state, eh.hr.workflow.transition and the abstract consumer mixin eh.hr.workflow.mixin. A registered service surface, eh.hr.workflow.engine, exposes apply_transition for programmatic callers such as the approval engine.
- What the mixin gives a record. A Selection state field whose options and order come from the definition, a state_label compute, a default that shows the initial state on an unsaved form, dynamic statusbar support, and action_transition to advance the workflow with audit emission and optional approval routing.
- Configuration and access. A Workflows form under the HR configuration menu (HR Admin only) with editable lists for states and transitions, including sequence handles, final flags, state kind, allowed groups, approval chain code and post-action method. Access rules grant HR Admin full control and HR Officer read-only.
- How it connects. Built on eh_hr_core: transitions emit the workflow.transition event through emit_platform_event, which lands in the hash-chained eh.hr.audit.log, and gated transitions hand off to eh.hr.approval.engine. It stands on the platform engines rather than extending standard Odoo models directly.
Honest about the edges
What this does not do, so nothing surprises you.
- This is platform infrastructure, not an end-user feature. On its own it ships the engine, the four models and an admin configuration screen; the visible draft to approve lifecycles come from the feature modules that consume the mixin.
- Approval-driven transitions require eh_hr_engine_approval to be installed and an active approval chain configured for the company. Without a matching chain, a gated transition raises rather than silently completing.
- Workflow definitions are not themselves company-scoped: there is one active definition per code. The approval engine it hands off to resolves chains per company, but the state machine shapes are global.
- The module ships no seed workflow data, no cron jobs and no wizards. States, transitions and approval gates must be created as configuration before a consuming model has a usable lifecycle.
- The mixin derives the statusbar and supports an OWL renderer at the platform level, but this module itself ships no JavaScript front end; it provides the backend form views only.
- Group-gating controls who may execute a transition; it does not by itself partition record visibility. Row-level access still comes from the consuming model's own record rules.
Odoo HR workflow engine, Odoo state machine, declarative workflow Odoo, draft submit approve done, configurable statusbar Odoo, group gated transitions, approval chain integration, post transition hooks, HR audit trail Odoo, self approval prevention, Odoo 19 Community HR, workflow mixin, no code workflow Odoo, HR platform engine, Odoo 16 17 18 19
Please log in to comment on this module