| 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 Kiosks
Turn a successful kiosk face match into a door unlock, with per-employee zone permissions and an append-only audit row on every attempt.
Why this module
Door Access Control for Kiosks
A match is not a free pass
The unlock only fires when the employee holds an active permission for the zone and today falls inside its valid-from and valid-to window. No permission, no unlock, and the denial is still recorded.
An audit row whatever happens
Allowed, denied for no permission, reader denied, reader error, no reader, or no zone: each path writes an eh.hr.access.event row with employee, zone, reader, site, device, outcome, reader response, and milliseconds elapsed.
One protocol, any hardware
Odoo POSTs a JSON unlock command to your reader webhook. Relay, Wiegand, MQTT, or proprietary boards sit behind a one-page bridge that exposes an HTTP endpoint, so the Odoo side stays hardware-agnostic.
Day in the life
From face match to open door
An employee steps up to the lobby kiosk and the face match succeeds. The kiosk JS fires the access trigger in the background while the usual success screen shows. The endpoint authenticates the device by its kiosk token, resolves the zone for that site, checks the employee holds a valid permission, then POSTs an unlock command to the zone reader's webhook. The bridge opens the door and auto-relocks after the configured seconds. An audit row lands on the Access events list with the outcome and round-trip time. If the employee has no permission, the door stays shut and the denial is logged for the manager to review.
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.
The unlock is fire-and-forget from the kiosk: door hardware delays never slow the visible match flow, and the server writes the audit row regardless of whether the browser request completes.
The trigger endpoint is public but requires a valid X-EH-Kiosk-Token mapped to an active terminal. No token returns 401, an unknown employee returns 404, and an employee from another company than the device is rejected.
The endpoint is throttled per kiosk token or client IP through the shared rate-limit model, returning 429 when over budget so a stuck or hostile kiosk cannot hammer the readers.
Permissions carry optional valid-from and valid-to dates evaluated in the request's local timezone, so a contractor badge expires on its own without anyone disabling the row.
No group has write access to access events, and even admins can only read, create, and delete. The audit trail cannot be edited after the fact through the application layer.
Zones, readers, permissions, and events all carry company_id with global record rules, and the endpoint matches zones only within the device's own company.
The daily retention sweep deletes stale events in a bounded batch per company against each company's own retention horizon and reports progress through ir.cron._commit_progress so the framework can reschedule the remainder.
A 2xx is recorded allowed, a 4xx reader_denied, and a 5xx or network failure reader_error with the truncated response text and elapsed milliseconds captured on both the event and the reader's last-status fields.
What is inside
Built to do the job, end to end.
- Zones and readers. eh.hr.access.zone names a controlled space with a URL-safe code, the kiosk sites that grant access to it, and its readers. eh.hr.access.reader holds the webhook URL, an optional bearer token visible only to admins, the HTTP timeout, and the auto-relock seconds sent to the bridge. A test-unlock button on the reader form helps commission the bridge.
- Permissions and audit. eh.hr.access.permission links an employee to a zone with optional validity dates and a unique row per employee and zone. eh.hr.access.event is the append-only outcome log with a colour-coded list, today-by-default filter, and group-by outcome, zone, employee, or day. Door access permissions also appear inline on the employee form.
- Endpoint, JS hook, and cron. The /eh_hr/kiosk/access/trigger controller resolves device, zone, permission, and reader then records the event. A small JS hook wraps the kiosk match call and fires the trigger only when the match returns success. A daily cron sweeps events past each company's retention horizon, defaulting to 365 days.
Honest about the edges
What this does not do, so nothing surprises you.
- Ships a single reader protocol, HTTP webhook. Relay, Wiegand, MQTT, or proprietary boards need a small bridge service that exposes an HTTP endpoint; that bridge is not included.
- One zone per kiosk site is resolved per unlock: when several zones share a site the first active match wins. Multi-zone-per-site routing is not yet supported.
- The unlock is a side effect of the match, not a gate on it. The kiosk shows its success screen regardless of whether the door actually opens.
- Auto-relock is sent to the bridge as a parameter; the relock itself is performed by your hardware, not enforced by Odoo.
- The reader webhook call is synchronous inside the trigger request and depends on the configured HTTP timeout, default four seconds.
- Requires the ERP Heritage attendance base and face kiosk modules; it extends that kiosk rather than providing standalone biometric matching.
Odoo 17 access control, door access control Odoo, biometric door unlock, face recognition door access, attendance access control, hr attendance door integration, kiosk door unlock, webhook door reader, Wiegand relay bridge Odoo, per employee zone permission, access event audit log, physical access control Odoo Community, ERP Heritage attendance suite, multi-company door access
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