EH HR Notify Engine
One send() call, every channel, resolved per user.
Why this module
EH HR Notify Engine
Every channel behind one send()
Feature modules pass a template code, a recipient and a payload dict. The engine resolves channels, suppresses duplicates, renders, and dispatches. No module wires email, SMS or in-app delivery by hand, so notification behaviour is consistent across the platform.
Preferences with real precedence
Each user can set channels per template or a wildcard default. A template-specific preference wins over the wildcard, the wildcard wins over the template default, and the template default falls back to in-app. The resolution order is covered by automated tests.
One channel failing never blocks the rest
Each channel dispatch runs in its own try block and logs the exception with channel, template and user context. If email is misconfigured, the in-app message still posts. Duplicate sends within a 60 second window are dropped when the caller supplies a dedupe key.
Day in the life
A leave approval fans out without anyone wiring it
The leave module calls engine.send('leave.approved', user, payload). The engine looks up the user's preference: they chose email for this template, so the wildcard SMS setting is ignored. It renders the subject and body with the payload values, creates a mail.mail and sends it. A second identical call arriving seconds later with the same dedupe key is silently dropped, so the approver is not emailed twice. If the email server were down, the failure is logged and the rest of the recipients still go through.
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 per-template preference beats the wildcard '*', which beats the template default, which falls back to in_app. Resolution is explicit, not an ASCII-sort accident, and is locked by tests.
When the caller passes a dedupe_key, a repeat send for the same (user, template, channel, key) inside a 60 second window is dropped. The in-memory cache self-trims past 5000 entries to bound growth.
Each channel dispatch is wrapped in its own try/except and logged with channel, template and user id. One channel raising never aborts the other channels or the other recipients.
The model ACL grants every internal user CRUD, so a record rule scopes each user to their own preference rows. HR admins see all for support. Cross-user reads raise AccessError, proven by tests.
SMS dispatch is skipped if the sms model or a contact number is absent. Push and webhook resolve a registered backend service and return quietly if none is installed, so a send never crashes on an unconfigured channel.
An unknown template code raises a clear UserError rather than dispatching nothing silently, so caller bugs surface early.
Placeholder substitution falls back to the raw source string on a missing or out-of-range key, so a payload gap degrades to an un-substituted template rather than an exception.
What is inside
Built to do the job, end to end.
- eh.hr.notification.template. Unique code, translatable name, subject, body, SMS body and push title/body fields, plus a comma-separated default_channels list. A SQL unique constraint guards the code.
- eh.hr.notification.preference. Per-user, per-template (or wildcard) ordered channel list, with a unique (user, template_code) constraint and stored quiet-hours fields. One preference row per user and template.
- Notification engine service. A registered eh.hr.notification.engine service exposing send(template_code, recipient, payload, channels, dedupe_key). It resolves channels, suppresses duplicates, renders and dispatches to in_app, email, sms, push and webhook handlers.
- Security and access. Model ACLs for HR admin and officer on templates, self-service CRUD on preferences, and two record rules: own-rows-only for users and see-all for HR admins.
Honest about the edges
What this does not do, so nothing surprises you.
- This is a service layer, not a UI app. It ships the models, security and the engine service; it does not add menus, form views or a notification centre screen.
- Despite the legacy summary wording, there is no digest feature: no batching, no cron and no scheduled roll-up. Notifications dispatch immediately on send().
- Duplicate suppression is opt-in. It only activates when the caller passes a dedupe_key, and the window is a fixed 60 seconds held in an in-memory per-registry cache, not a persisted log.
- Quiet-hours fields are stored on the preference record but are not yet enforced by the engine; sends are not deferred or held during quiet hours.
- Out of the box only in-app and email dispatch are self-contained. SMS requires Odoo's sms module and a contact number; push and webhook are adapter slots that no-op until you register a backend service.
- Template rendering is lightweight {placeholder} substitution via str.format, not full QWeb expression evaluation, despite a stale help string on the body field.
- Targets Odoo 18 Community. No external service is called by this module itself and nothing phones home.
odoo notification engine, odoo hr notifications, channel abstract notifications odoo, per user notification preferences, odoo in-app notification, odoo email notification service, odoo sms notification, push notification adapter odoo, webhook notification odoo, notification template odoo, duplicate notification suppression, odoo 18 hr platform, notification dispatch service, odoo community hr, erp heritage hr platform
Please log in to comment on this module