| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Attendances (hr_attendance)
• Discuss (mail) • Employees (hr) |
| Community Apps Dependencies | Show |
| Lines of code | 3852 |
| Technical Name |
eh_hr_attendance_access_control |
| License | LGPL-3 |
| Website | https://www.erpheritage.com.au/ |
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Attendances (hr_attendance)
• Discuss (mail) • Employees (hr) |
| Community Apps Dependencies | Show |
| Lines of code | 3852 |
| Technical Name |
eh_hr_attendance_access_control |
| License | LGPL-3 |
| Website | https://www.erpheritage.com.au/ |
Door Access Control
When an authorised employee matches at a kiosk, the suite calls the configured reader's HTTP webhook to unlock the door or open the zone. Permissions are per employee per zone. Every unlock attempt, allowed or denied, lands in an append only audit row.
Day in the life
Match at the kiosk. Hear the door click. Walk in.
A worker walks up to the workshop tablet. Face match succeeds, hr.attendance is created. The kiosk JS hits /eh_hr/kiosk/access/trigger, the suite checks the worker has permission for the workshop zone, looks up the reader, and POSTs to the configured URL. The relay bridge on the wall flips the door strike. The worker walks in. Six seconds. The audit row shows who, what zone, what reader, response code, milliseconds elapsed. Manager finds out next week that someone tried to enter a zone they are not on; the audit trail tells them who, when, and what reader denied them.
Overview
What this module does, in one read.
eh_hr_attendance_access_control adds a webhook based door unlock layer to the ERP Heritage face kiosk.
Sites get zones; zones get readers; employees get permissions per zone. The Odoo side stays vendor neutral by speaking HTTP only. Customers with relay, Wiegand, MQTT, or proprietary boards run a one page bridge in front of their hardware that exposes an HTTP endpoint. The data plane: zones, readers, permissions, and events.
Capabilities
Eight things this module gives you, with no padding.
Zones, readers, permissions
eh.hr.access.zone is a named controlled space tied to a kiosk site; eh.hr.access.reader is a bridge endpoint with URL, optional bearer token, and optional auto relock seconds; eh.hr.access.permission is one row per (employee, zone) with optional effective from and to dates.
Webhook trigger after match
The kiosk JS posts to /eh_hr/kiosk/access/trigger after a successful face match. The server resolves zone, permission, and reader, then calls the reader's URL with a JSON body that the bridge translates into a relay flip.
Per employee zone permissions
Permissions are one row per (employee, zone), with optional effective from and to dates. Workers can be on the workshop until their certification lapses, then the permission expires automatically without an HR rebuild.
Six outcome states
Allowed; denied (no permission); reader denied; reader error; no reader for zone; no zone for site. Each outcome captures who, where, why. Filters and dashboards distinguish a config gap from a permission denial.
Append only event log
Every unlock attempt writes to eh.hr.access.event with employee, zone, reader, site, device, outcome, reader response code, milliseconds elapsed. Read only for managers; one place to answer "who tried what door, when".
Daily retention sweep
A daily cron prunes event rows past the configured horizon, batched so a busy site does not freeze a worker. Retention horizon is per company under People Operations Settings.
Optional bearer token per reader
Each reader can carry an optional bearer token sent in the Authorization header on every webhook call. The bridge verifies the token before flipping the relay; no random unlock from a wandering HTTP client.
Vendor neutral protocol
Odoo POSTs JSON to the configured URL. Relay, Wiegand, MQTT, and proprietary boards each run a one page bridge in whatever language their hardware supports. No SDK to license, no vendor lock in.
Frequently asked questions
Honest answers to the questions a buyer asks.
Why HTTP webhook instead of a vendor SDK?
SDK lock in. Each reader vendor has their own protocol, their own auth, their own breaking changes. HTTP is the smallest interface that works for all of them. The customer writes a one page bridge in front of their hardware that exposes an HTTP endpoint; the bridge translates Odoo's JSON into whatever the board needs.
What does the unlock request body look like?
A JSON object with action set to unlock plus employee_id, zone_id, and reason. The bridge verifies the optional bearer token and translates the action into a relay flip, a Wiegand emit, an MQTT publish, or whatever the board accepts.
What if the reader is offline?
A reader_error event is logged with the response detail. The kiosk feedback tells the worker the door did not open; HR sees the error in the audit list and dispatches a fix. There is no retry queue; on next match, a fresh request is made.
Can a worker have time bound access?
Yes. Permissions carry optional effective from and to dates. The trigger checks that the request time falls inside the window; outside the window, a denied event is logged.
Does a denied event prevent the attendance row?
No. The face match has already created the attendance row at the moment the access trigger fires. A worker may be allowed on the floor but not in a particular zone; access denial is independent of attendance posting.
Please log in to comment on this module