QR Sign-On (Mobile)

Field workers sign on to a prestart from the mobile app by scanning the prestart’s QR code. Scanning records their attendance end-to-end — one scan, one tap.

The QR code

Each published prestart renders a unique QR from the web app. It encodes:

https://app.lacroo.ai/p/<prestartId>?org=<orgId>&project=<projectId>&action=sign-on

The QR is only shown once the prestart is published — draft prestarts have no QR.

The scan → sign-on flow

1. In the mobile app, the worker scans the QR (in-app scanner, or the universal link opens the app once AASA / Android intent filters ship).
2. The app routes to a dedicated sign-on confirm screen and loads the prestart via getPrestartSignOnView(orgId, projectId, prestartId) → GET /v1/orgs/{orgId}/projects/{projectId}/prestarts/{prestartId}/sign-on-view.
3. The screen shows what they’re signing onto (prestart, date, project, location, supervisor). One tap captures GPS (if already permitted) and calls signOnPrestart(...), inserting into prestart_sign_ons.

Authorization — by project membership

The sign-on view is authorized by project membership, not prestart RBAC scope. This is deliberate: labour-hire / supplier field workers belong to a different org than the host project, and scoped same-org workers may not be the prestart’s supervisor/creator. Both are legitimate attendees. The endpoint therefore uses the require-membership org gate (ExtractOrgContextRequireMembership) — a project member (same-org or cross-org) can load a published prestart to sign on; the sign-on write path already allows self-sign-on the same way.

Because this read has no RBAC-scope backstop, membership is enforced even for same-org callers, so a same-org non-member cannot read a prestart by guessing its id.

What the worker sees on failure

Errors surface clearly instead of a blanket “not found”:

What it does not expose

The sign-on view is a minimal projection: prestart id/display id, datetime, shift, project name, location name, supervisor name, and whether the caller has already signed on. It never returns drafts and omits office-only prestart detail. The supervisor name is an intentional, necessary disclosure (the worker needs to know who runs the shift).

Sign-on QR codes (project-wide and location)

A project’s printed sign-on QR (project-wide, or one per location) opens a sheet where a field worker picks the date and shift, then a supervisor from ONE list called Supervisors. Supervisors who have published a prestart for that date and shift come first, each with their prestart(s) right under their name (“Prestart · Day · 6:45 am”, “0 signed on”); the others follow, each reading No prestart yet.

The sheet has one main button, with Close stacked below it, and it names what happens:

• A supervisor with a prestart: Select a prestart to continue (inactive) until the worker taps one of that supervisor’s prestarts, then Go to prestart. It opens that prestart so the worker reads it and then signs. A supervisor with exactly one prestart is already selected, so the button reads Go to prestart at once.
• A supervisor without one: Sign on prior to prestart. It signs the worker on the same way Start Shift does: their docket for the shift (a supplier worker only) plus their attendance, at the scanned location. The docket shows on the docket workbench straight away, and joins the supervisor’s diary and prestart for that day and shift when they are created or published. If the worker later signs another supervisor’s prestart for the same shift, that sign-on lands on the same docket, which keeps its supervisor. A worker with no supplier assignment gets attendance only. Office users keep their own direct sign-on.
• No supervisor picked: no main button.

A worker cannot sign on prior to the prestart of a supervisor who has published one: the button is not offered, and the server refuses it (409, the sheet opens that prestart). Start Shift follows the same rule.

The project setting

Allow workers to sign on prior to the prestart (Config, Custom Fields, Sign-on acknowledgements) is No on every project until an admin turns it on. While it is No, the Sign on prior to prestart button is greyed out, with the line “Your supervisor hasn’t published a prestart yet.”, and the server refuses the sign-on (409, prior_to_prestart_not_allowed). The check on the supervisor’s published prestart comes first. Office sign-ons, which name no supervisor, are not affected.

Sign-on questions come first

When the project has sign-on acknowledgements, signing on prior to prestart asks the same questions as a prestart does (from the QR sheet and from Start Shift), under the same rules: each answer’s action (A, B or C) applies, a refused answer stops the sign-on and is recorded, and a flagged answer is recorded on the sign-on. The answers, refusals and audit are stored with the others, so reports and the red flag see them. The sign-on shows as Signed on prior to prestart in Onsite Workers and the Sign-ons list.

If a sign-on is blocked

When the project has sign-on acknowledgements configured, the worker answers each one on this screen before Sign On becomes available. Answering No to an acknowledgement set to Action 2 blocks the sign-on: the worker sees the project’s own message, and no sign-on is recorded. The attempt is kept, and shows in the field user’s profile under Refused sign-ons.

Answering No to an acknowledgement set to Action 1 still signs the worker on, and shows the project’s message afterwards.

See also: Sign-Ons for the office-side flow and how to configure acknowledgements.