Custom Engineering / Nimex Solutions
Dynamic Organization & Approval Engine
Confirmations, purchases and custom documents need the right manager’s approval, and standard Odoo has no generic way to put any button behind one. Nimex built an engine that routes the request up the real reporting lines, enforces it on the server and runs the action the moment the right person approves.
The problem
Approvals that live in e-mails are approvals nobody can prove.
Standard Odoo offers approval flows for some documents, each configured its own way, and none for the button a company actually cares about on its own models. The usual workaround is a message to the manager and a promise to wait — which holds until someone is in a hurry.
Hard-coding a workflow per document does not scale either: every reorganisation means changing code, and an approval that only hides a button in the browser can still be bypassed by an import or an API call.
What we engineered
One engine for every button, one chart for every reporting line.
- Rules, not workflows
A rule picks a model and one of its form buttons (read from the views, or a typed method), the authorised users, an optional fallback approver, an optional record condition and a company.
- Enforced on the server
The ruled method is wrapped in the model registry: screens, RPC calls and imports all need an approved, unused request for that record. While pending, only chatter and activity fields are writable.
- Routed by the real hierarchy
Skip or step chain mode over Employees’ manager field; the next approver is computed from the live chain at every step, so reorganisations need no change to the rules.
- Decided where people work
Approve or decline from the form banner, the chatter activity or the daily task board; seeded decline reasons and a “Fix and resubmit” activity.
- Runs as the approver
On final approval the original method runs as the approver with the stored arguments; its result opens in the approver’s browser and the requester receives a note and a live notification.
- Organisation chart
A drag-and-drop chart where HR changes managers, adds reports and archives managers on the canvas; its side panel lists the rules each person can approve.
How it works
From the button press to the approved action.
- Define the rule
Model, button, authorised users, fallback approver, condition (for example Total > 100,000) and company. Chain mode is a setting: Skip or Step.
- Send for Approval
A user who is not authorised sees “Send for Approval” instead of the button; the record is saved, a note is asked for, and request REQ/0007 is created in state Pending.
- Route the first step
Skip: the first authorised manager above the requester. Step: the direct manager. Managers without a user are skipped; the fallback approver is used only when nobody in the chain is authorised.
- Lock and notify
The record is locked, the button reads “Awaiting approval · approver”, a banner shows the steps, and the approver gets an “Approval: Confirm” activity in the chatter and on the task board.
- Forward or decide
A manager who is not authorised approves and the step becomes Forwarded; the next approver is read from the current hierarchy. An authorised approver’s decision closes the request.
- Approved
The request becomes Approved, the original method runs once as the approver, the lock is released, and the requester is notified with Open.
- Declined or cancelled
Decline records a reason and creates “Fix and resubmit” for the requester; Cancel Request sets the request to Cancelled and releases the lock.
Integration points