HR Policy Engine for Odoo 17
Move HR thresholds, multipliers and eligibility rules out of code and into versioned, per-company policy records evaluated by a safe, side-effect-free DSL.
Why this module
HR Policy Engine for Odoo 17
A DSL that cannot hurt you
The evaluator handles only literals, context reads, comparisons, boolean logic, arithmetic and an if-then-else node. Anything else is rejected with a clear error. It never imports user code, never calls Python builtins and never touches the ORM during evaluation, so a policy body is safe to expose to HR officers through the JSON editor.
Right rule, right company
Each policy is keyed by a stable code and scoped to a company with an optional department and employee tag. Resolution returns the department-specific record first, then falls back to the company-wide rule. A global record rule restricts reads to the requesting company so one officer cannot see another company's rule set.
Tune rules without a deploy
Thresholds, multipliers and formulas become editable records with valid-from and valid-to date windows, so a change takes effect on a date you choose rather than on a release. Feature modules call the engine for the value in force, which keeps the same constant out of a dozen separate models.
Day in the life
One late-arrival rule, evaluated everywhere
Attendance asks the engine for the lateness grace threshold for an employee on a given date. The engine resolves the policy by code, prefers the employee's department over the company default, checks the date window, then evaluates the JSON body against the attendance context and returns the typed result. HR edited that number in a form last week; no model was touched and no release was cut.
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.
resolve() returns the department-scoped policy when the employee has a matching department, and otherwise falls back to the company-wide record that carries no department and no tag.
When an evaluation date is supplied, the domain filters on valid_from and valid_to, treating empty bounds as open, so a future-dated rule does not apply before its start.
A global ir.rule forces every policy read through company_ids, so an officer in one company cannot see or resolve another company's rule set.
A database constraint enforces one active policy per code, company, department, tag and active flag, blocking two conflicting live rules for the same scope. The constraint is declared through both the modern Constraint API and the legacy list so it holds across Odoo 16 to 19.
An unrecognised DSL key, or an operator given the wrong number of arguments, raises a UserError instead of silently returning a wrong value.
Division by zero returns None rather than raising, comparisons against a missing value return False, and a missing context path resolves to None so a partial context does not crash evaluation.
config() tolerates a body stored as a JSON string, which happens when a Json field is seeded from XML text, by parsing it back to a dict before returning it.
What is inside
Built to do the job, end to end.
- eh.hr.policy model. A versioned, scoped rule record carrying a code, a translatable name, company, optional department and employee tag, a JSON body, a valid-from and valid-to window, an active flag and notes. Ordered by code then version. Built on the platform mixin, so each record receives a correlation id on create.
- Policy engine service. Registered under eh.hr.policy.engine with resolve(), evaluate() and config() methods. evaluate() resolves the policy then runs the restricted DSL against a context dict using dotted paths such as employee.tenure_months. config() returns the resolved body as a plain dict for accrual or expiry documents that are configuration rather than expressions.
- The restricted DSL. Supports literals, context reads via a dollar-path node, the comparisons eq ne gt ge lt le, boolean and or not, the arithmetic add sub mul div, and an if-then-else node. No imports, no builtins, no ORM access during evaluation.
- Security and access. Three access tiers: HR admin reads, writes, creates and deletes; HR officer reads, writes and creates; employee self-service reads only. A global per-company record rule scopes every read. Policies appear under the HR security configuration menu for officers.
- JSON body editor. The form presents the policy body in an ACE code editor in JSON mode, so a rule author edits the document directly with syntax highlighting rather than through scattered settings fields.
Honest about the edges
What this does not do, so nothing surprises you.
- This is platform plumbing, not a standalone app. It is consumed by EH HR feature modules such as attendance and leave; on its own it ships the policy model, the engine service and the editor, with no end-user workflow screens.
- The version field is a static counter with a default of one and is read-only. This build does not auto-increment it or retain prior revisions, so it is not a revision-history store; treat it as a manual stamp.
- There is no result cache in this build. Each evaluate call resolves and evaluates against the current records, so caching, if needed, belongs to the caller.
- The employee tag is a scope dimension and part of the uniqueness constraint, but resolve() matches on department and company; it does not actively select a record by an employee's tag.
- The DSL is intentionally minimal. It has no loops, no string functions, no date arithmetic and no user-defined functions; rules that need those belong in Python in the calling feature module.
- Requires eh_hr_core for the platform mixin, the service registry and the security groups; it is not designed to run independently of the EH HR Platform.
odoo 17 hr policy engine, odoo hr business rules, leave cap configuration odoo, overtime multiplier odoo hr, hr eligibility rules odoo, per company hr policy odoo, rule engine odoo community, json dsl odoo hr, configurable hr thresholds odoo 17, odoo 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.
Please log in to comment on this module