| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Attendances (hr_attendance)
• Discuss (mail) • Employees (hr) |
| Lines of code | 1428 |
| Technical Name |
eh_hr_attendance_base |
| 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) |
| Lines of code | 1428 |
| Technical Name |
eh_hr_attendance_base |
| License | LGPL-3 |
| Website | https://www.erpheritage.com.au/ |
Attendance Suite Base
The shared engine every ERP Heritage attendance module quietly stands on. Biometric consent with explicit lifecycle. Kiosk site and device registry with rotating tokens. Append only audit trail with retention sweeps. Multi company isolation enforced in code, not paperwork.
Day in the life
A new starter walks in on a Monday and the kiosk just works.
HR opens the employee record, captures consent in plain English, and ticks granted. The base writes one consent row with the validity window the company configured. The new starter walks up to the reception tablet, pairs once with the one shot PIN HR issued, and is recognised on every clock in from then on. Behind the curtain a daily cron expires past due grants, prunes withdrawn rows past the retention horizon, and trims the kiosk audit trail to the configured horizon. The CFO who asks for a Fair Work audit on Friday afternoon does not need to phone the IT team. They open Audit Trail, filter by date, export. No spreadsheets, no SaaS dashboards, no surprise.
Overview
What this module does, in one read.
eh_hr_attendance_base ships the privacy primitives, kiosk infrastructure, and audit guarantees the rest of the ERP Heritage people operations suite plugs into.
It auto installs as a dependency of any sibling module so an operator never picks it manually. Consent records gate every biometric and geolocation capture downstream. Sites and devices live on first class models with rotating opaque tokens. Every kiosk event lands in an append only log a manager can read and an auditor can export, and nobody can edit.
Capabilities
Ten things this module gives you, with no padding.
Per employee consent lifecycle
eh.hr.consent records pending, granted, withdrawn, and expired states with explicit transitions. Configurable validity and retention windows per company. Withdrawing consent cascades to the matching biometric template the next time the kiosk runs.
Kiosk site and device registry
A first class site model for each clock in location, optional geofence radius and centre. A device registry with rotating opaque tokens, last seen tracking, IP and user agent on every heartbeat. Revoke a lost or pinched tablet from one screen.
One shot device pairing PIN
Issue a short lived numeric PIN, the device redeems it once for a long lived opaque token. PINs cannot be replayed and never live in the same row as the issued token. Re pair a refurbished tablet without rebooting the kiosk service.
Append only kiosk audit trail
Every register, heartbeat, match attempt, success, failure, geofence pass, geofence fail, consent transition, and exception raise lands in eh.hr.kiosk.event with timestamp, device, employee, confidence, and IP. Read only for managers and auditors; no edit, no delete, no rewrite.
First class exception model
Late, no show, missed check out, location mismatch, low match confidence, geofence violation. Each exception carries severity, employee, kind, message, and resolution state. Future modules raise to it; managers triage from one place.
Daily retention sweeps
A daily cron expires consents past their validity, deletes withdrawn consents past retention, and trims the kiosk audit trail to the configured horizon. Compliance is a background process, not a Friday afternoon checklist.
Multi company isolation by record rule
Every model is company scoped. Global ir.rule entries enforce per company isolation on read, write, and delete. A consultant working across three tenants never sees one tenant's audit trail bleed into another.
Privilege based group system
Suite namespaced groups for User, Manager, Admin, and Auditor. ACL CSVs reference these groups, never upstream HR groups directly. Migration scripts promote existing users so an upgrade does not lock anyone out.
Stable public APIs for downstream modules
log() for audit events, raise_exception() for attendance exceptions, issue_pairing_pin() for device pairing. Sibling modules import these by name and stay decoupled from each other. New modules slot in without surgery.
Privacy by design throughout
Raw biometric images never persist on the server. Only embeddings live in the database, tied to a granted consent. No third party cloud dependency. No phone home telemetry. Your database, your roof, your rules.
Compared
How this module stacks up.
Workflow
Install. Configure. Pair. Forget.
Four steps; the same shape every other module in the suite uses, so a finance or HR team learns the pattern once.
Install
Every sibling module in the suite declares this base as a dependency, so installing any of them pulls the base in. You can also install it on its own to lay the data model first.
Configure
Set retention windows, default consent text, match threshold, and kiosk idle reset under People Operations > Settings.
Pair
Create a kiosk site for each clock in location. Issue a one shot PIN. The tablet pairs and rotates its own token from then on.
Forget
The retention crons run on schedule. Sibling modules build on the primitives. The base hums quietly behind the curtain.
Why Heritage
Where this module leads, where it matches, what we are honest about.
- Privacy primitives baked into the data model, not bolted on
- Append only audit, never edited, never silently mutated
- One shared engine for a dozen sibling modules
- Standard kanban, list, form, and search views
- Multi company isolation via global ir.rule
- Suite namespaced privilege groups
- This is plumbing; pair it with a kiosk module to clock in
- No third party cloud; on prem only
- Privacy is enforced in code; the legal review is yours
Engineering
Eight engineering rules we hold ourselves to.
Privacy by design.Raw biometric images never persist on the server. Only embeddings live in the database, tied to a granted consent.
No silent fallbacks.Missing consent, missing site, missing device token each surface explicit messages naming the unresolved field.
Append only audit.Kiosk events are read only for managers and auditors. No edit, no delete, no rewrite. The trail tells the truth.
Multi company aware throughout.Every model is company scoped. Global ir.rule entries enforce per company isolation on every operation.
Per record savepoints in crons.Retention sweeps wrap each iteration in a savepoint so one bad row never stops the batch.
Stable public APIs.log(), raise_exception(), issue_pairing_pin(). Sibling modules import these by name and stay decoupled from each other.
Plain Python and OWL.No third party cloud dependency, no proprietary ML server, no vendor lock in. Your stack stays portable.
Capability focused descriptions.No competitor names in code or docs. Every claim describes what the module does, not what it replaces.
Frequently asked questions
Honest answers to the questions a buyer asks.
Does this run on Odoo 19 Community?
Yes. The module targets Odoo 19 Community and uses only standard ORM and view APIs. No Enterprise dependencies, no proprietary modules required.
Do I need to install this on its own?
No. Pick any sibling module in the ERP Heritage attendance suite and the base auto installs. You only ever tick this one if you want the data model in place before the kiosk modules.
Does it touch the standard hr.attendance model?
Only by reference. The base ships its own consent, kiosk, and exception models, and it sits alongside hr.attendance rather than rewriting it. Sibling modules write to hr.attendance directly through the standard API.
What does the audit trail look like?
Each kiosk event records timestamp, device, employee, event kind, optional confidence, and optional IP. ACLs make the trail read only for managers and auditors; nobody can edit or delete a row. A daily cron trims past the configured retention horizon, and the trim itself is logged.
What happens when an employee withdraws consent?
The consent row transitions to withdrawn and the matching biometric template is deactivated the next time the kiosk runs. The cascade is logged in the audit trail. After the retention horizon the withdrawn row itself is removed by the daily cron.
How is multi company isolation enforced?
Every model carries a company_id and a global ir.rule that restricts read, write, and delete to the user's allowed companies. Site, device, audit, exception, and consent rows are all scoped per company. A consultant rolling out three tenants on one Odoo never sees the trails cross.
Can I extend the audit trail with my own event types?
Yes. Inherit eh.hr.kiosk.event in your own module and extend the kind selection. The log() public API accepts the new kind by name; the rest of the audit pipeline picks it up without further work.
Please log in to comment on this module