Health Screen for Attendance Kiosk
A configurable yes/no health declaration that runs at the kiosk before the face match, denies entry on flagged answers, and keeps an immutable audit row of every declaration.
Why this module
Health Screen for Attendance Kiosk
Stop entry before the face match runs
The declaration shows after pairing and before face capture starts. Any yes answer on a deny-flagged question records the declaration as denied, shows a deny screen, and never reaches the face match for that session.
Every declaration is a snapshot you can defend
Each submission writes one readonly row carrying the per-question answer array, the decision, the device, the site, and the company. The question text is captured at submission time, so rewording a question later never rewrites a past audit row.
Configure it without touching code
Operators write the question prose, set deny-on-yes per question, choose every-clock-in or once-per-day cadence, set the retention horizon, and turn the whole screen on or off per company from settings.
Day in the life
A morning at the reception tablet
Staff tap to pair, then the tablet asks the day's health questions before any face capture begins. Answer everything No and the kiosk proceeds straight into the normal face match. Answer Yes on a flagged question and the kiosk records a denied declaration, logs a denied kiosk event against it, shows a deny screen, and tells the person to see their manager. With once-per-day cadence the screen only reappears the next local day. A manager later opens the declaration list to see who was allowed or denied, on which device, with the exact answers as they stood that morning.
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 answer snapshot stores the question text at submission time, so editing or rewording a question never corrupts the historical declaration rows that referenced it.
The server helper computes the day boundary in the company timezone, falling back to UTC on an unknown timezone, so a once-per-day check honours the local day rather than the server clock.
Global record rules scope both questions and declarations by company_ids, and questions with an empty company apply to every company, so a shared database keeps each company's data and question set isolated.
The daily sweep walks companies, deletes only declarations past each company's horizon up to a batch cap of 2000, and reports progress through ir.cron._commit_progress so the framework can re-run without losing its place.
Both endpoints require a valid active kiosk device token and are rate limited per scope, returning 401 for an unknown token and 429 when a caller exceeds its budget.
The submit endpoint rejects a non-array body, skips entries that are not objects or that reference a non-existent question, and coerces answers to a strict boolean before deciding allowed or denied.
What is inside
Built to do the job, end to end.
- Two models. eh.hr.health.question holds the prose, sequence, deny-on-yes flag, active flag and optional company. eh.hr.health.declaration holds one readonly row per submission with the answer snapshot, decision, employee link, device, site and company.
- Two kiosk endpoints. A GET questions endpoint returns the active questions and cadence for the device's company, and a POST submit endpoint records the declaration and returns allowed or denied. Both authenticate with the kiosk device token and are rate limited.
- Kiosk JS hook. A script loaded into the face kiosk shell intercepts the welcome screen, runs the declaration when the company has it enabled and there are active questions, and shows a deny screen on a flagged answer instead of starting face capture.
- Per-company settings. Enable the screen, choose every-clock-in or once-per-local-day cadence, and set the declaration retention in days, all from Settings as fields related to the company.
- Retention cron. A daily ir.cron runs _cron_retention_sweep, deleting declarations older than each company's horizon in capped batches and reporting progress to the cron framework.
- Access and isolation. ir.model.access grants read to users and auditors, full edit on questions to managers and admins, and read-only declarations to managers and auditors. Global record rules enforce per-company scoping. Four seeded questions ship inactive for the operator to adopt.
Honest about the edges
What this does not do, so nothing surprises you.
- Requires the ERP Heritage attendance base and face kiosk modules. It is an add-on to that kiosk, not a standalone attendance system.
- Questions are simple yes/no with a deny-on-yes flag. There are no scale, free-text or multiple-choice answer types, no branching logic and no scoring.
- The declaration runs before identification, so a declaration row is not automatically linked to the employee the face match later identifies; the employee field is populated only when set explicitly.
- Deny blocks the face match and logs a denied kiosk event; it does not raise a separate attendance exception record or send a notification on its own.
- The once-per-day skip on the device is held in browser local storage, so clearing kiosk storage or using a different browser can prompt the declaration again that day.
- Declarations store the answer snapshot and a free-text notes field in clear text and are removed only by the retention cron at the configured horizon; there is no per-field encryption in this module.
- This is a workplace screening and audit tool, not medical advice, diagnosis, or a regulatory compliance certification.
health declaration kiosk Odoo 18, fitness for work screen, attendance health questionnaire, deny entry on health answer, workplace health check in, COVID screening kiosk, hr attendance health declaration, per company health questions, declaration audit trail, health declaration retention, Odoo 18 Community attendance kiosk, kiosk health screening add-on, yes no health questions, ERP Heritage attendance
Need this fitted to the way you work?
ERP Heritage delivers end to end Odoo work: Odoo Implementation, Customization and Development, Integration, Migration, Consultation, Support and Training. We help teams put this module into production, shape it to their process, and keep it running.
We work with businesses across Australia (Melbourne, Sydney, Brisbane, Perth, Adelaide, Canberra) and the Middle East (Dubai, Abu Dhabi, Riyadh, Jeddah, Doha, Kuwait City, Muscat). Start a conversation at erpheritage.com.au or email info@erpheritage.com.au.
Languages
Available in 19 languages
The interface ships translated out of the box. Switch language in Odoo and the fields, menus, and messages follow.
Please log in to comment on this module