| 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 engine for biometric consent, kiosk registry, attendance exceptions, and an immutable audit trail on Odoo 18 Community.
Why this module
Attendance Suite Base
Consent gates the capture
Every face, fingerprint, voice, photo, or geolocation capture is tied to an eh.hr.consent record with explicit pending, granted, withdrawn, and expired states. At grant time the exact consent prose is snapshotted onto the record and an expiry date is stamped from the company validity setting, so the audit copy cannot drift if the default text is later edited.
An audit trail you cannot edit
Kiosk events land in eh.hr.kiosk.event through a single log() entry point and are read-only in the UI: create, edit, and delete are all disabled on the list and form. Managers and a dedicated read-only auditor role can inspect device, employee, confidence, IP, and timestamp, but no one can rewrite history.
One base, many modules
Sites, devices, consent, exceptions, and the audit log live here once, so each ERP Heritage attendance module reuses the same registry and the same record rules instead of reinventing them. LGPL-3 source on disk, multi-company aware throughout, no cloud dependency.
Day in the life
A site supervisor pairs a new clock-in kiosk and an employee withdraws consent.
The supervisor opens the kiosk site, clicks to issue a one-time pairing PIN valid for five minutes, and reads it onto the new tablet. The tablet POSTs its site code and PIN to the pairing endpoint, the PIN is consumed on first use, and the server issues a long opaque device token recorded against the site with a device-registered audit event. From then on every heartbeat carries that token in a header; an unknown or revoked token is rejected. Later an employee asks to stop using face clock-in. HR opens their consent record and withdraws it, which stamps the withdrawal time and clears the enrolled flag. The next nightly retention cron leaves the withdrawn record in place for the company audit window, then deletes it once past retention, while the kiosk audit log is trimmed to its own longer horizon. Every step is company-scoped and logged, and the employee keeps a PIN or manual fallback.
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 kiosk pairing PIN is a six-digit code valid for five minutes and consumed on first successful use. A wrong site code, an expired PIN, or an unknown site each returns a distinct error, and a paired device receives a server-issued opaque token rather than reusing the PIN.
Device tokens are generated with a cryptographic random source and carry a unique database constraint so a collision is rejected, not silently accepted. Heartbeat and whoami endpoints reject any request without a valid active token with a 401, and a sub-one-second heartbeat burst is rate limited with a 429.
Both daily sweeps are batched by an explicit limit so a database with years of stale rows cannot freeze a worker. Remaining work is reported through the cron progress API so the framework re-triggers until the backlog clears, and the consent and audit crons run as independent jobs so a failure in one does not block the other.
Granting a consent freezes the displayed consent text onto the record and computes expiry from the company validity months at that moment. A constraint blocks a granted record without a grant date, a withdrawn record without a withdrawal date, and any withdrawal dated before the grant.
Every model carries company_id under a global record rule restricting rows to the user's active companies. A regular user additionally sees only their own consent and exception records through own-only rules, while managers see the full set within their companies.
Resolving an attendance exception is a no-op once already resolved and reopening is a no-op once already open, so a double-click cannot churn the resolver, timestamp, or audit trail. The raise_exception API also writes a matching audit event for every exception it creates.
What is inside
Built to do the job, end to end.
- Biometric and location consent. eh.hr.consent covers face, fingerprint, iris, voice, photo, and geolocation. Four-state lifecycle, grant-time expiry from the company validity setting, frozen consent text, optional evidence attachment, and a per-employee face-consent state surfaced and searchable on the employee form.
- Kiosk site and device registry. eh.hr.kiosk.site holds per-location timezone, optional geofence with validated latitude, longitude, and radius, and a URL-safe code unique per company. eh.hr.kiosk.terminal issues a per-device token, tracks last seen, last IP, and user agent, and offers rotate-token and revoke actions.
- Attendance exception log. eh.hr.attendance.exception is a first-class model for late, early, no-show, missed check-out, location mismatch, low match confidence, geofence violation, liveness failure, duplicate, and manual events, with severity, resolve and reopen actions, and a public raise_exception API for other modules.
- Read-only kiosk audit trail. eh.hr.kiosk.event records device registration, heartbeats, match attempts and outcomes, attendance posts, consent changes, exceptions, geofence and liveness results, and errors. One log() entry point, read-only in the UI, retained to a configurable horizon.
- Token-authenticated kiosk endpoints. HTTP routes for device pairing, heartbeat, and whoami. Pairing trades a one-time PIN for a long-lived token; every other call requires the token header and returns live site config including idle reset, match threshold, and geofence settings.
- Security roles and retention config. Four roles: user, manager, admin, and a standalone read-only auditor, with version-portable privilege grouping applied at install. Company settings cover consent validity, withdrawn and audit retention months, default face consent text, match threshold, and kiosk idle reset.
Honest about the edges
What this does not do, so nothing surprises you.
- This is the shared base layer. It ships the consent, site, device, exception, and audit models plus the pairing and heartbeat endpoints; the in-browser face capture, server-side match, and attendance posting live in a separate face kiosk module that depends on this base.
- Despite the wording in the packaged manifest, this module does not auto-install on its own. It is installed as a dependency of the ERP Heritage attendance modules that require it, or manually.
- Geofence, liveness, and match-confidence values are stored and have audit event types and exception types reserved for them, but the actual geofence enforcement, liveness check, and face matching are performed by the downstream capture modules, not by this base.
- The pairing PIN store is in-process per worker, which suits the manual admin-plus-operator pairing flow; a multi-worker deployment retries pairing on the worker that issued the PIN.
- Withdrawn and expired consent records are intentionally deleted once past the configured retention window, since at that point their purpose is the audit window only. Set the retention months to match your local documentation requirement before relying on long-term retention.
Odoo 18 Community attendance, biometric attendance consent Odoo, face attendance kiosk base, time and attendance audit log, kiosk device registry token, attendance exception management, geofence attendance site, employee consent lifecycle GDPR, hr_attendance extension, multi-company HR attendance, consent retention cron, kiosk pairing PIN device token, employee clock in clock out, T and A audit trail Odoo, ERP Heritage people operations
Please log in to comment on this module