| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Attendances (hr_attendance)
• Discuss (mail) • Employees (hr) |
| Community Apps Dependencies | Show |
| Lines of code | 4541 |
| Technical Name |
eh_hr_face_liveness |
| License | LGPL-3 |
| Website | https://www.erpheritage.com.au/ |
| Versions | 16.0 17.0 18.0 19.0 |
Attended Face Capture
An attended-capture step in front of the face match. The kiosk shows a prompt during check-in and records the outcome the browser reports, so every attempt is logged for attendance audit. The server does not verify the outcome. This is an audit and convenience feature, not an anti-spoofing or liveness-detection control.
Day in the life
"Please blink slowly twice." A moment later, the day starts.
A worker steps up to the kiosk. The welcome screen hands off to an attended prompt: blink slowly twice. The browser runs the prompt and reports an outcome to the server, which records it as reported. On a reported pass, the kiosk continues into face match; on a reported fail or timeout, it shows a polite retry screen. Every attempt, pass, fail, or aborted, lands in the attended-capture log, so a fortnightly review can spot the depot with a spike of failed attempts. The server does not check the outcome; it keeps an honest record of what the kiosk reported.
Overview
What this module does, in one read.
eh_hr_face_liveness slots an attended-capture prompt into the kiosk welcome to capture transition.
The kiosk shows a prompt, the browser reports an outcome, and the server records it as reported (client-asserted, not verified). Every attempt is logged so a manager can see patterns over time. A daily retention cron deletes rows older than the configured horizon (default 180 days).
Capabilities
What this module gives you, with no padding.
Attended prompt at check-in
The kiosk asks the user for an action (such as a blink) before the face match runs, and reports an outcome to the server. The prompt is run by the browser; the server records the reported result.
Honest, auditable record
Each attempt is stored with the outcome marked client-asserted, so reports never overstate what happened. The record is for audit and dispute resolution, not identity assurance.
Per company configuration
Toggle the prompt on or off per company, set the prompted blink count (default 2), and set the maximum wait in milliseconds (default 8000) before the attempt is reported failed.
Every attempt logged
One row per attempt with outcome, prompt shown, duration, reported blink count, device, site, and (after match) the employee. Read only for managers, queryable.
Three outcomes, no ambiguity
Passed, failed, or aborted, as reported by the client. Aborted means the user walked away mid prompt; failed means the timeout elapsed; passed means the client reported success. Filters know which is which.
Daily retention sweep
A daily cron deletes attempt rows older than the configured horizon (default 180 days), batched so a database with months of stale rows does not freeze a worker.
Wired into the kiosk shell
The kiosk JS hook intercepts the welcome to capture transition; no template work in the consuming module. Install, configure, and the prompt slots in.
Honest about what it is not
This is not an anti-spoofing or liveness-detection control. The outcome runs in the browser and the server records it as reported, so a photo or video can pass and a modified client can report any result. For real anti-spoofing, add a server-side passive-liveness model.
Workflow
Install. Toggle on. Tune. Watch.
Install
Pick eh_hr_face_liveness. Depends on the suite base and the face kiosk.
Toggle on
Open Settings under People Operations. Enable the attended-capture prompt on the company. The kiosk picks it up on the next page reload.
Tune
Set prompted blinks and the timeout. Defaults of two within eight seconds work for most sites; raise either if retries bother you.
Watch
Open the Attended captures list. Filter by failed or aborted to find sites with a spike of failed attempts.
Frequently asked questions
Honest answers to the questions a buyer asks.
Does this prevent a photo or an impersonator?
No. This is not an anti-spoofing control. The outcome is computed by the browser and recorded as reported, so a printed photo or a phone video can pass, and a modified client can report any outcome. Use it for an attendance-audit record, not identity assurance.
How long does the prompt add to a clock in?
In testing, a cooperative user passes within one to two seconds. The default eight second timeout sets the upper bound on a failed attempt.
Is the outcome verified on the server?
No. The browser computes the outcome; the server records it as client-asserted. There is no server-side verification, so do not treat a recorded pass as proof of a real person. For high security paths, add a server-side passive-liveness model.
Can I keep the prompt off but still log attempts?
No. The toggle controls both the prompt and the row write. With it off, no attended-capture rows are produced. Switch it on for the audit trail.
How long is data retained?
Each attempt row is kept for the configured horizon (default 180 days), then deleted by a daily retention cron.
Please log in to comment on this module