Health Screen for Attendance Kiosk
A configurable yes or no health declaration that runs at the kiosk before face capture, denies entry on any flagged answer, and keeps a frozen answer snapshot for audit.
Why this module
Health Screen for Attendance Kiosk
Block sick entry before it becomes an attendance row
The declaration runs after pairing and before face capture. A yes on any deny on yes question marks the declaration denied and the kiosk shows a deny screen, so the face match never runs and no attendance row is created for that attempt.
Snapshots that survive reworded questions
Each declaration stores a JSON snapshot of the question text, the answer, and the deny on yes flag captured at submission time. Operators can reword or reorder questions later without changing what an old audit row says was asked and answered.
Policy lives per company, not in code
Each company turns the screen on or off, picks a cadence of every clock in or once per local day, and sets a retention horizon in days. Questions are activated, reworded, and reordered from the standard list view by an HR admin.
Day in the life
A morning at the reception tablet
A worker walks up to the paired kiosk. The tablet calls the health endpoint, loads the active questions for the device company, and shows them before the welcome screen. Two taps of No each, Submit, and the server records an allowed declaration with the full answer snapshot, logs a kiosk event, and the face capture loop begins. Later a different worker taps Yes on the unwell question. The server records the declaration as denied, the kiosk shows an entry not permitted screen, and the face match never starts, so no attendance row is created. The denied declaration sits in the Health Declarations list, read only, filtered to today, ready for a manager to follow up.
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 freezes the question text, the answer, and the deny flag at submission time, so editing or reordering a question later never rewrites the meaning of an older declaration.
Two global record rules scope data by company. Declarations are visible only to their own company, and questions are visible to their company plus shared questions with no company set, which apply database wide.
The submit endpoint browses and checks each referenced question. Entries that are not dicts, carry a non integer id, or point at a missing question are skipped rather than crashing the declaration.
Both endpoints require the kiosk device token in the X-EH-Kiosk-Token header and match it against an active terminal. A missing or unknown token returns HTTP 401 and no data leaves the server.
The questions endpoint is capped at 120 hits and submit at 60 hits per window per token or client IP through the shared rate limiter, returning HTTP 429 when a caller goes over budget.
A daily cron walks each company, computes a cutoff from its retention days, and deletes declarations past the horizon in batches capped at 2000 rows per run so a large backlog cannot run the job away.
When a company has the screen turned off, the questions endpoint returns enabled false with an empty list and the kiosk proceeds straight to face capture, so installing the module changes nothing until it is switched on.
Declaration list and form are create false and edit false, and security grants no write to managers or auditors. Rows are written by the kiosk endpoint and removed only by the retention cron or an admin unlink.
What is inside
Built to do the job, end to end.
- Two models. eh.hr.health.question holds the yes or no prose with a deny on yes flag, sequence, active flag, and an optional company. eh.hr.health.declaration holds one row per submission with the decision, the JSON answer snapshot, the kiosk site and device, optional employee link, and company.
- Two kiosk endpoints. A GET at /eh_hr/kiosk/health/questions returns the active questions and cadence for the device company. A POST at /eh_hr/kiosk/health/submit takes an array of yes or no answers, decides allowed or denied, writes the declaration, and logs a kiosk event.
- Kiosk JS hook. A script loaded into the face kiosk shell intercepts the welcome screen, fetches the questions, renders Yes and No buttons per question, requires every question answered, and on deny shows an entry not permitted screen instead of starting face capture.
- Company settings and cron. Settings expose the enable flag, the every clock in or once per local day cadence, and the retention horizon in days as related fields. A daily ir.cron runs the per company retention sweep as the root user.
- Security and menus. Access rules give read to users and auditors, edit on questions to managers and admins, and keep declarations read only in the backend. A Health menu lists declarations with today, allowed, denied, and grouping filters; questions live under attendance configuration.
- Tests. Model tests cover question creation, the already declared today helper including the denied skip, and the retention sweep deleting an aged row. HTTP tests cover disabled and enabled companies, missing token, allowed and denied submissions, and the stored snapshot.
Honest about the edges
What this does not do, so nothing surprises you.
- The cadence gate of once per local day is enforced on the kiosk client through local storage. The submit endpoint records every submission it receives and does not itself reject a second declaration on the same day, so a device reset or a different browser can produce more than one row.
- A denied declaration stops the face match and prevents an attendance row for that attempt. It does not raise a separate attendance exception record and does not push a notification; follow up is by a manager reviewing the read only Health Declarations list.
- The employee link on a declaration is optional and is not populated by the submit endpoint, because the declaration is taken before face identification. Declarations are correlated by site, device, and time rather than by a guaranteed employee match.
- This module targets Odoo 17 Community and depends on the ERP Heritage attendance base, face kiosk, and core modules. It is not a standalone health app and does not work against stock hr_attendance.
- Questions are a flat yes or no list. There is no branching, scoring, free text answers from the worker, or multi step questionnaire logic.
- Retention deletes whole declaration rows after the horizon. There is no archival export step, so set the retention days to match how long your audit policy needs the records kept.
health declaration kiosk Odoo 17, attendance health screening, deny entry on health answer, fitness for work questionnaire, kiosk health questions Odoo, COVID screening attendance, workplace safety declaration, per company health policy, health declaration audit trail, declaration retention cron, face kiosk health step, multi company attendance kiosk
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