EH HR Workflow Engine
State machines as data, not Python.
Why this module
EH HR Workflow Engine
Steps are data, not code
States and transitions live in eh.hr.workflow.definition records. The status field derives its options from the definition, ordered as the definition orders its states. An administrator adds a step from the config screen; no developer, no deploy, no downtime.
Transitions that refuse the wrong move
Every advance is checked against the definition: a transition must be declared from the current state, a final state forbids any further move, and group-restricted transitions reject users outside the allowed groups, with an admin bypass for setup.
One engine, every workflow module
The same mixin backs each feature module on the platform instead of every module re-implementing draft to submit to approve to done. One audited transition path, one status widget contract, one place to reason about how records move.
Day in the life
An administrator adds an approval step without a developer.
A leave correction used to go straight from submitted to approved. Compliance now wants a manager check in between. The administrator opens the workflow definition, adds a review state, and inserts two transitions, submit-to-review and review-to-approved, marking the second as requiring approval and tagging the approver group. The next correction raised carries the new step immediately, its status bar shows review between submitted and approved, and the approve button only appears for the approver group. The person who submitted the correction cannot approve their own request, because the engine captures the original submitter before handing the work to the approval engine. No module was redeployed; the change was three rows of configuration.
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.
A state marked final forbids any further transition, even one a misconfigured definition mistakenly declares from it. is_final is the authoritative terminal marker, checked before the transition lookup, so a done record cannot be nudged back into motion.
action_transition resolves the transition strictly from the record's current state. A transition code that is not declared from where the record actually sits raises a clear UserError instead of silently writing an out-of-order state.
Transitions carry an allowed-groups set. A user outside every allowed group is refused, with an explicit admin bypass so a configurator can drive workflows during setup. An empty group set means any owner may execute the step.
When a transition opens an approval chain, the real submitter is captured as submitted_by before the engine is called under sudo, so the user who fired the gated transition cannot later approve their own request even if they hold an approver group.
The state write is unconditional; requires_approval opens a chain as a side effect that gates the follow-up approve or refuse step, not the current one. This avoids records appearing stuck in their pre-submit state and the duplicate approval requests that the older skip-the-write behaviour produced.
action_transition accepts the transition code positionally for server-side callers or via the transition_code context key for view header buttons, which cannot pass positional arguments, so the same method is callable from both code and a form button.
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 eh.hr.workflow.mixin that consuming models inherit by declaring a workflow code.
- What the mixin gives a record. A status Selection whose options come from the workflow definition, a default initial state on new records, action_transition to advance, a computed state_label, and a platform event emitted on every transition for audit.
- Configuration and access. An admin-only Workflows screen under HR configuration to edit states, transitions, allowed groups, approval flags and post-action methods. HR administrators get full write; HR officers get read-only visibility.
- Programmatic entry point. A registered eh.hr.workflow.engine service exposes apply_transition(record, code), the path the approval engine uses to fire the matching transition once a chain approves.
Honest about the edges
What this does not do, so nothing surprises you.
- This is engine infrastructure for the EH HR Platform, not a standalone end-user app. On its own it provides the configuration screens and the mixin; the visible workflows come from the feature modules that consume it.
- It requires eh_hr_core and is designed for the platform's models. It does not retrofit a state machine onto arbitrary standard Odoo models out of the box; a model must inherit the mixin and declare a workflow code.
- Approval routing, escalation ladders and approver assignment live in the separate approval engine. This module only opens a request and reacts to the follow-up transition; it does not implement the approval chain itself.
- Audit immutability and the platform event log are provided by the core platform layer, not by this module. This module emits transition events into that log rather than owning the tamper-evidence mechanism.
- There is no proration, scheduling, cron, or multi-company partitioning logic in this module. Those concerns belong to the feature modules and engines that sit on top of it.
odoo 17 workflow engine, odoo hr state machine, configurable approval workflow odoo, declarative workflow odoo, odoo statusbar workflow, draft submit approve done odoo, group gated transitions odoo, no code workflow configuration, odoo workflow mixin, self approval guard odoo, odoo 17 community hr, erp heritage hr platform
Please log in to comment on this module