Sign-Ons

Sign-ons record which workers attended the prestart safety meeting. This provides an auditable record of who was briefed before starting work.

See also: Workforce Log for Core’s 25-column sign-on export.

Signed on prior to prestart

A sign-on made before the supervisor published a prestart is tagged Signed on prior to prestart in the Sign Ons workbench and Onsite Workers. The tag stays after the docket is linked to the prestart. The workbench has a Signed on prior to prestart filter, and the CSV export honours it.

Add Sign-On

1. On the Sign-Ons tab, user clicks “Add Sign-On”
2. A dialog opens showing project members who haven’t already signed on
3. User clicks “Sign On” next to a member
4. Calls addSignOn(orgId, projectId, prestartId, userId, metadata?, acknowledgementResponses?)
5. Go handler inserts into prestart_sign_ons with signed_at = NOW()
6. A repeat of the same sign-on replays the existing row as an idempotent 201 — it is not an error

Remove Sign-On

1. User clicks “Remove” on a sign-on row
2. Confirmation dialog
3. Calls removeSignOn(orgId, projectId, prestartId, signOnId)
4. Go handler deletes the row (hard delete — sign-ons are not soft-deleted)

Sign-On Display

Each sign-on shows:

• Name and email of the user
• Role badge (e.g., Supervisor, Labour, Operator)
• Signed at: date and time in the project’s time zone, e.g. 04/05/2026, 06:45 am (Dates & Times)

Workers With No Supplier

A worker’s sign-on raises a billing docket only when the worker has a supplier. Without one, the sign-on records attendance and nothing else. The Sign-Ons tab says so under the worker’s supplier: “No supplier: no docket. Set the supplier to create it.” (the mobile prestart shows a No supplier badge).

Setting the worker’s supplier on the field users screen bills the shifts they already signed on for: the save creates the missing dockets, exactly as the sign-on would have. So does assigning a classification or a machine rate, or a new assignment. Running it twice never makes a second docket.

For a batch of sign-ons that got no docket (for example after a data fix), backend/api/cmd/backfill-signon-dockets bills a project’s native sign-ons since a date through the same code. It is a dry run unless -dry-run=false, never touches a sign-on migrated from Core, and refuses production unless -i-am-the-owner is passed.

One Docket Per Shift

A worker has one docket per project, date and shift. If they tap Create Docket (Start Shift) after their sign-on already made that docket, the app opens it instead of making a second one. Two quick taps open the same docket too. A different shift, date or project still gets its own docket.

A docket the worker raised before any prestart (from the sign-on QR or Start Shift, with no diary yet) counts too: a prestart sign-on for the same date and shift lands on it, whatever supervisor it names, and the docket keeps its own.

When the worker signs a second supervisor’s prestart for the same shift, or picks a different supervisor on Create Docket, that supervisor is added to the docket as an associated supervisor. The docket then shows in their diary for that day, under Associated Dockets. Its primary supervisor does not change.

The rule is FindWorkerIndividualDocketForShift, checked under one per-worker-shift lock (backend/pkg/workershiftdocket) that the sign-on, the crew fan-out and Create Docket all take. Invariant dockets_23 counts any worker shift that still has two.

Real-Time Updates

Sign-on changes fire LISTEN/NOTIFY via the notify_prestart_sign_on_change trigger. The project_id is denormalized on the prestart_sign_ons table specifically to enable this without JOINs in the trigger function.

Acknowledgements

A project can ask every worker to answer a set of acknowledgements before they sign themselves on. Configure them under Config → Custom Fields → “Sign-on acknowledgements”.

Each acknowledgement carries:

• the text the worker reads, in the order the items are listed
• the two button labels, which default to Yes and No
• the action that governs a negative answer

The three actions, with the names the “Edit actions” screen shows:

When more than one item is answered negatively, the highest action wins: C over B over A.

Where the red flag shows:

• the Sign Ons workbench, beside the worker’s name
• the workbench CSV, as acknowledgement_flag
• the field user’s profile, on the Recent Sign-ons table

A blocked attempt records no sign-on. It shows in the field user’s profile under Refused sign-ons, with the acknowledgements the worker answered No to.

One acknowledgement can be linked to the Drug & Alcohol report. A project has at most one linked acknowledgement. A worker who answers it positively shows a green tick on that day’s report.

Every acknowledgement needs its text and both button labels before the list can be saved. Saving an empty list turns the check off for the project, so the editor asks you to confirm first.

Security

• A worker can always sign themselves on. Signing someone else on, and removing any sign-on, needs prestarts.edit on the project
• The user being signed on must be a project member
• A repeat sign-on replays the existing row instead of creating a second one

Key Files

See also: Onsite Workers