| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Attendances (hr_attendance)
• Discuss (mail) • Employees (hr) |
| Community Apps Dependencies | Show |
| Lines of code | 1510 |
| Technical Name |
eh_hr_attendance_base |
| License | LGPL-3 |
| Website | https://www.erpheritage.com.au/ |
| Versions | 16.0 17.0 18.0 19.0 |
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Attendances (hr_attendance)
• Discuss (mail) • Employees (hr) |
| Community Apps Dependencies | Show |
| Lines of code | 1510 |
| Technical Name |
eh_hr_attendance_base |
| License | LGPL-3 |
| Website | https://www.erpheritage.com.au/ |
| Versions | 16.0 17.0 18.0 19.0 |
Attendance Suite Base
The shared compliance engine under every ERP Heritage attendance module: biometric consent lifecycle, kiosk device registry, exception log, and an immutable audit trail for Odoo 17 Community.
Why this module
Attendance Suite Base
Consent is a record, not a checkbox
Every face, fingerprint, photo or geolocation capture is gated by an eh.hr.consent row with explicit pending, granted, withdrawn and expired states. The exact consent prose shown to the employee is snapshotted onto the record at grant time, so the audit copy cannot drift if the company default text later changes.
An audit trail managers cannot rewrite
Every kiosk event lands in eh.hr.kiosk.event with timestamp, device, employee, confidence and IP. Fields are read-only and no role has write access to the log. Managers and auditors read it; only an admin can purge it on the configured retention horizon. That is a defensible record for a fair-work dispute.
One registry for every capture type
Site model, device registry, exception log and audit trail live here once, so the face kiosk, reporting and roster modules share a single source of truth instead of each reinventing devices and consent. Install it alone, or let any ERP Heritage attendance module pull it in as a dependency.
Day in the life
A site supervisor pairs a new kiosk and triages the morning's exceptions
From the kiosk site form the supervisor clicks Pair a new device. Odoo shows a six-digit PIN valid for five minutes and one use only. The tablet at the door POSTs the site code and PIN and receives a long opaque device token it stores once; every later heartbeat carries that token, and an unknown or revoked token is turned away with a 401. Through the morning each clock-in writes an audit event. Later the supervisor opens the Exceptions list, sees the late check-ins and one missed check-out raised by the kiosk, resolves each with a note, and the resolution is stamped with their user and the time. Overnight the retention crons expire any consent past its validity window and trim the audit log to the company horizon, in bounded batches that never freeze a worker.
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 pairing PIN is single-use and expires after five minutes. It is consumed on first success and a wrong site code is rejected, so a leaked or stale PIN cannot mint a second device token.
Kiosk event fields are read-only and no group holds write access on the log. Managers and the read-only auditor role can view it; only an admin can delete, and only via the retention purge.
Each daily sweep is capped by a batch limit and reports remaining work through ir.cron progress so the framework re-triggers. A database with years of stale rows is drained over successive runs rather than locking a worker on one long delete.
Withdrawal demands a withdrawn-on date and rejects any withdrawal dated before the grant. Withdrawn or expired rows are kept for the configured audit window, then deleted, so the record's purpose ends cleanly with its legal retention.
Global record rules scope all five models to the user's active companies, and a plain attendance user sees only their own consent and exception rows while managers see the team. Device tokens and the kiosk PIN are gated to manager and admin groups.
The consent prose is copied onto each consent record at grant time. Editing the company default later never alters what an already-granted employee agreed to, so the audit copy is the version they actually saw.
Heartbeats inside one second of the device's last-seen time are rejected with a 429, damping a runaway or misbehaving kiosk without extra infrastructure.
What is inside
Built to do the job, end to end.
- Five core models. eh.hr.consent (consent lifecycle), eh.hr.kiosk.site (locations with optional geofence coordinates), eh.hr.kiosk.terminal (device registry with per-device token), eh.hr.attendance.exception (typed, severity-graded exceptions), and eh.hr.kiosk.event (the read-only audit trail). Each is company-scoped and chatter-tracked where it matters.
- Two public APIs for other modules. eh.hr.kiosk.event.log(event_type, ...) is the single entry point any module uses to write the audit trail, and eh.hr.attendance.exception.raise_exception(employee, type, ...) creates an exception and logs a matching audit event in one call. Build face, roster or geofence modules on top without touching the base internals.
- Four roles and a kiosk controller. User, Manager, Admin and a standalone read-only Auditor group, wired to a single access-level dropdown by the install hook. An HTTP controller exposes device pairing, token-authenticated heartbeat, and a whoami bootstrap, with client IP and user-agent recorded on each call.
Honest about the edges
What this does not do, so nothing surprises you.
- This is the base engine. It stores consent, devices, sites, exceptions and the audit trail and exposes the APIs to write them, but it does not itself capture faces, compute biometric matches, or post attendance. Those live in the face kiosk module that depends on this one.
- Geofence coordinates and radius are stored on the site and served to the kiosk, but this module does not enforce a geofence or evaluate GPS position. Enforcement belongs to the mobile and geofence modules.
- Exceptions support resolve and reopen with a stamped resolver. There is no multi-step approval or escalation ladder, and no automatic detection: exceptions are raised by other modules or entered manually.
- Pairing PINs are held in process memory for their five-minute life. On a multi-worker deployment the admin retries pairing on the worker that issued the PIN; the token itself, once issued, is stored in the database and works across all workers.
- The optional kiosk fallback PIN is a manager-restricted field, not a hashed secret. Use it as a convenience fallback, not as a primary credential.
- Targets Odoo 17 Community. The retention crons rely on the Odoo 17 cron progress mechanism.
Odoo 17 attendance, biometric consent Odoo, face attendance kiosk, time and attendance Odoo, employee clock in clock out, kiosk device registry, attendance exception log, kiosk audit trail, hr_attendance base, GDPR consent attendance, consent retention policy, multi-company attendance, time clock Odoo Community, geofence attendance, attendance compliance Odoo
Please log in to comment on this module