| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Attendances (hr_attendance)
• Discuss (mail) • Employees (hr) |
| Community Apps Dependencies | Show |
| Lines of code | 4770 |
| Technical Name |
eh_hr_attendance_access_control |
| License | LGPL-3 |
| Website | https://www.erpheritage.com.au/ |
| Versions | 16.0 17.0 18.0 19.0 |
Door Access Control for Odoo 18
When an authorised employee matches at the kiosk, the door unlocks and an audit row is written. Every time, whatever the outcome.
Why this module
Door Access Control for Odoo 18
The unlock is gated, the audit is not
The controller resolves the employee, the device's zone, and the active reader, checks the permission window, then calls the webhook. An event row is written on every path: allowed, denied for no permission, reader denied, reader error, no reader, no zone. You always see what happened.
One reader protocol, any hardware behind it
The module POSTs a JSON unlock command to a configured URL with an optional bearer token and a configurable timeout. Relay, Wiegand, MQTT, or a proprietary board all sit behind a one page bridge that exposes that endpoint. The Odoo side stays hardware agnostic.
Door delays never slow the kiosk
The kiosk fires the unlock as a side effect of the match and forgets the result. The employee already has their success screen; the access outcome lands in the audit trail. Slow or unreachable door hardware cannot stall the visible attendance flow.
Day in the life
A normal morning at the side entrance
An employee looks at the kiosk by the side door and the match succeeds. The kiosk quietly POSTs the employee id to the access trigger. The module finds the zone for that kiosk site, confirms the person has an active permission inside its valid window, and POSTs an unlock to the reader's bridge with a five second auto relock. The relay fires, the bridge returns 200, and an event row records allowed with the reader's reply and 180 ms elapsed. A contractor whose permission lapsed yesterday matches at the same door; the unlock never fires and the row reads denied. At month end the retention cron trims events older than the company's horizon, a few thousand at a time.
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.
Six outcomes are distinguished and stored, not collapsed into pass or fail: allowed, denied for no permission, reader denied, reader error, no reader for zone, no zone for site. The reader response text and elapsed milliseconds are kept alongside.
A permission only opens the door when active and inside its valid from and valid to dates. is_currently_valid is checked at trigger time, so a lapsed or not yet started grant is treated as denied rather than ignored.
Access events carry no write permission for any role; the timestamp and fields are readonly. Managers and auditors read, admins read and create and unlink, nobody edits a recorded outcome.
The retention sweep walks each company with its own retention horizon, deletes in capped batches, and reports progress through _commit_progress so a long sweep stays inside its scheduler budget.
The trigger rejects an employee whose company does not match the calling device's company, and four global record rules scope zones, readers, permissions, and events to company_ids.
The public endpoint requires a valid kiosk device token or returns 401, and is rate limited per token or client IP to 60 hits before returning 429. A malformed body or non integer employee id returns 400.
A network failure or 5xx is recorded as reader error with the captured message, a 4xx as reader denied, and a 2xx as allowed. The reader's last status, last response, and last unlock time are written back for diagnosis.
What is inside
Built to do the job, end to end.
- Four models, one clear chain. Zone is a named controlled space tied to one or more kiosk sites. Reader is the bridge endpoint with URL, optional bearer token, timeout, and auto relock. Permission is employee plus zone plus an optional date window. Event is the append-only audit row per attempt.
- Public trigger endpoint. A token authenticated POST route resolves the device, employee, zone, and active reader, validates the permission, calls the webhook, and creates the event. It returns a small JSON body with the outcome, reader name, event id, and elapsed time.
- Kiosk hook and reader test. A JavaScript hook wraps the face match fetch and fires the unlock on success without blocking the screen. A test unlock button on the reader form lets you confirm the bridge is reachable and authorised during commissioning.
- Security and retention. Per company record rules on all four models, role based access where events stay readonly, a unique permission row per employee and zone, zone code format validation, and a daily retention cron with a per company day horizon.
Honest about the edges
What this does not do, so nothing surprises you.
- Ships one reader protocol only, HTTP webhook. Relay, Wiegand, MQTT, or proprietary boards require a small bridge service you run in front of your hardware that exposes an HTTP endpoint. The bridge is not included.
- The unlock is triggered by a successful face match at the kiosk, so the module depends on the ERP Heritage face kiosk and attendance base. It is not a standalone badge reader or card access system.
- When a kiosk site maps to more than one zone, the first active zone wins. Multiple zones per single site is not yet resolved per reader.
- The kiosk fires the unlock fire and forget. The door outcome is recorded in the audit trail, not surfaced as a block or retry on the kiosk success screen.
- Targets Odoo 18 Community. No cross version guarantee is made here for other releases.
odoo 18 door access control, biometric door unlock odoo, face recognition access control, hr attendance access control, kiosk door unlock integration, per employee zone permissions, webhook door controller odoo, wiegand relay bridge odoo, access event audit trail, multi company access control, odoo 18 community attendance, physical access control module
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.
Please log in to comment on this module