Changelog

Production plan import • Deliveries are shown before you confirm, and inconsistent delivery cells stop the import

The reconciliation step now lists the delivery and return rows, how they group into shared deliveries, how many have no control registered, explicitly no control or selected controls, and how many declare an ADR class. The row preview shows the delivery reference with its group size, the control state and the delivery description beside each row, so what each delivery will become is visible before anything is written. A delivery column on a row whose type is not a delivery or a return, a control value that is not a control name, an ADR class outside 1 to 9, a dangerous goods description without a class, or rows sharing a delivery reference that disagree on any of these, are listed with the row number and what to correct, and the import cannot be confirmed until the sheet is fixed. Nothing is guessed, and nothing is moved into the comment.

Technical focus: Blocking findings come from the pure interpretation step and are refused at every layer before the first write, so a sheet with an inconsistent delivery cell imports nothing (all-or-nothing).

Production plan • Delivery details travel with the plan export and import

A plan export now carries, on every delivery and return row, five optional columns for the delivery the row belongs to: the delivery reference, the delivery description, the gate control, the ADR class and the dangerous goods description. Importing such a file re-creates the deliveries with their description, their gate control (blank for not registered, None for explicitly no control, or the control names joined with +), their ADR class and their dangerous goods description. Rows that share a delivery reference land on one shared delivery, so a truck carrying several plan rows survives the round trip as one delivery. The D-number in the file is only that grouping key: every imported delivery gets a new number, and an exported number is never reused. Driver, vehicle, phone and contact person are not in the file; they stay in Deliveries. A file without the five columns imports exactly as before, and the export preview says how many deliveries carry driver or vehicle details the file leaves behind.

Technical focus: ONE writer attaches imported deliveries inside the import transaction; the export keeps NULL (not registered) and none (explicitly no control) apart, and an exported D-number is a grouping key only, never reused.

Appearance • Dark reaches the whole application

The dark appearance covers the workspace, My pages, the platform admin, the login and reset pages, the clock terminal, public signup and registration links, supplier pages, QR pages and Plan Live: tables, cards, tabs, inputs, dropdowns, modals, alerts, badges and the browser's own controls. Status colours keep their meaning in both appearances. Printed documents, PDFs and email are deliberately unchanged and stay light.

Technical focus: ONE semantic token vocabulary in main.css with a single dark value set; page-local styles are routed through the same tokens rather than a second dark block.

Appearance • Choose System, Light or Dark

HR Cluster now has a dark appearance. Pick System, Light or Dark from the control in the header beside the language switch (in the menu drawer on a phone) or on My profile under Appearance. System follows your device and switches with it; Light is the appearance HR Cluster has always had; Dark is new. Your choice is saved to you, so it applies in every workspace you sign in to and on every device where you sign in, and the login page and the clock terminal on that device follow it too. Nothing changes until you choose: everyone starts on System, and on a device set to light that looks exactly like before.

Technical focus: Stored on the person (users.appearance / platform_admins.appearance), never on the membership; NULL means never chosen and resolves to System. core/appearance.php owns the model, and the theme is resolved before first paint, so there is no flash.

Signup • Dates in your language, and the role stays readable on a phone

On a public signup page the day headers and every shift date now read in the page's language (ons 23. sep. rather than Wed 23 Sep), and the workspace signup link form follows. On a narrow phone a long shift title no longer squeezed the role label down to a lone ellipsis: the title is shortened instead, and the role and the age requirement stay whole.

Login • The login box fits a small phone

On a 320px-wide screen the login box kept its desktop inset, which left the e-mail and password fields only 175px wide. The box now narrows its inset on small screens; larger screens are unchanged.

Login • The reason you were signed out no longer disappears

When a session timed out and the login page explained why, the message faded after a few seconds, so a person who came back to the machine later saw a bare login form. The message now stays until you close it or sign in.

Navigation • A wide tab no longer scrolls past its own first letters on a phone

When a tab in a scrolling pill navigation was wider than the screen, opening it centred the tab and cut off its beginning, so a long list name read from its middle. A tab that fits is still centred; one that does not now shows its start, and the arrow scrolls the rest.

Deliveries • The vehicle fields in the delivery form are laid out like the vehicle card

When you add a vehicle to a delivery in the workspace, the fields now sit in the same two rows as on the public registration link and the supplier portal: registration number with the look-up button beside colour, then body style beside make and model. Same fields, same look-up; only the layout changed, so the workspace form and the link read as one form.

Deliveries • The per-vehicle control override is gone from the delivery

A delivery carries one vehicle, so the Override control for this vehicle editor on the vehicle card asked the Gate control question a second time on the same record. It has been removed. The delivery's Gate control is the one decision for the trip; the vehicle card now shows the control that applies beside Remove. A vehicle's standing control requirement, set on the vehicle itself, is unchanged, and no delivery in use carried a per-vehicle override.

Risk assessments • The reference no longer overflows on a phone

In the risk assessment list on a phone, the reference (RA-2026-901) spilled under the status badge and read as a stray fragment. Card cells on narrow screens no longer inherit the desktop column widths, on every list that uses the card layout.

Accreditation • The record form fits a phone

On a phone, the accreditation record form squeezed first and last name, phone and e-mail, and the validity pair side by side, leaving the phone number a few pixels wide. Those rows now stack one field per line on narrow screens and stay two per line on a desktop.

Production plan • A delivery row lists the vehicle, its details and the driver on separate lines

A delivery row in the production plan used to put the registration number and the driver on one Vehicles line. It now shows one Vehicle line per vehicle with the registration number, make and model and year, a Vehicle details line with the dimensions, weight and colour when the vehicle record holds them, and a Driver line with the driver's name and phone. A missing registration number or driver is still stated rather than left out, and is still highlighted when the arrival is less than 24 hours away. The same lines appear in the Checklist view, which now shows the delivery block too, in the Suppliers view, on the downloaded plan and checklist PDFs, in the morning briefing's plan and checklist documents (including the personal checklist), and on Plan Live links, where the phone still appears at the Full level only.

Deliveries • A delivery has a driver and a contact person, in the same order as the registration link

The delivery window opened from the production plan and from Deliveries now asks for the same two people the public registration link and the supplier portal always asked for, in the same order: the vehicle, then the driver of that vehicle, then the contact person for the delivery. Tick "Use this driver as the contact person" when they are the same, and the contact fields follow the driver. When no vehicle is recorded yet, the vehicle fields are shown right away instead of behind an Add vehicle button, and a registration number typed there is attached when you save. Request information now prefills the contact person first. When a delivery registered through the public link or the supplier portal is approved, the person who registered it becomes its contact person.

Production plan • Freetext supplier names join on one line

A plan row naming two suppliers as freetext showed the comma between them on a line of its own, so the supplier cell read as three lines and the phone card read the names with a stray comma between them. The names now join on one line.

Vehicles • The Details button and the details window on a phone

On a phone, the Details button on a vehicle card overflowed into the registration plate, and could run past the card when the vehicle carried two access chips. It now sits beside the plate on the first line. In the details window, the request's contact person was labelled Owner type; it is labelled Contact, as in the list, and the details stack in one column on narrow screens instead of squeezing every value into a narrow column.

Deliveries • Approving a pending delivery keeps you on the queue

Approving a proposed delivery on Pending deliveries sent you to the delivery list, so clearing several pending rows meant navigating back after every decision. Approve now returns to the queue, as Reject already did, with a message naming what happened. The queue's heading and intro also line up with the table below them.

Production plan • Tools now confirm what they did

On the Tools tab of the production plan, linking freetext supplier names, merging duplicate names, changing a label or renaming one refreshed the page as soon as it was done, and the refresh took the confirmation with it: the page came back with every tool collapsed and no message, as if nothing had happened. The result is now shown as a message after the refresh, and the tool you used opens again. Messages for a run over more than one row also showed a placeholder instead of the number of rows; they now state the count.

Deliveries • Phone layout of the list, the pending queue and the delivery window

On a phone, the folded item rows of a shared delivery were shown on every card although the toggle read Show items; the status colour of an overdue delivery was painted as separate patches on each field; the Pending deliveries table was wider than the screen; and the delivery window's fields were squeezed into narrow columns. Folded rows stay hidden, the colour covers the whole card, the pending queue and the supplier's proposal tables lay out as cards, and the delivery window's fields stack on narrow screens.

Deliveries • One status per delivery, shared with its plan rows

A delivery and the plan rows linked to it kept separate statuses that nothing kept in step, so a delivery marked Completed could still sit in an overdue row while its plan row read Not started. There is one status now. Setting it in the delivery window applies it to every linked plan row, under the plan's own rules for which changes are allowed; a change refused for a row leaves the delivery as it was and the message says why. Changing a plan row's status updates its delivery: a shared delivery shows the least advanced status among its rows, so it is completed only when every row is. Existing deliveries were brought in step with their rows. Ongoing is set through Start task on the plan, not from the delivery window.

Production plan • The Suppliers view shows delivery details

In the Suppliers view of the production plan, a delivery row showed only its title, comment and need. The delivery reference, the vehicles and driver, the gate control and any dangerous goods note were missing on screen, although the PDF of the same report printed them. The view now shows the same delivery block as the plan under the row's title, and clicking the reference opens the delivery over the report, exactly as it does on the plan.

Sign-in • No more second attempt after an idle timeout

After being signed out for inactivity, the first sign-in attempt could bounce back to the sign-in page as expired and demand the password a second time. The form's protection token was tied to a browser session identifier that the server may quietly replace between showing the form and receiving it. It is now tied to a dedicated cookie that stays put for the whole visit, so the first attempt is accepted. The protection itself is unchanged: a form posted from another site is still refused.

Data integrity • Shift assignments are now removed together with their shift

The database now enforces that a shift assignment always belongs to an existing shift: if a shift row is ever removed outright, its assignments go with it instead of lingering as records no page can show. Nothing changes for day-to-day use, because cancelling or deleting a shift in the schedule keeps the shift on record and only marks it as deleted; the rule exists so that a maintenance operation or a repair can never leave stray assignment rows behind. No existing data was affected.

Dashboard • Email follow-ups card

The Workforce dashboard has a new card showing how many email addresses in the account are waiting for a fix because mail to them bounced or was refused. It opens the Email delivery settings page, where each address is listed and can be resolved. The card is shown to administrators, who are the ones able to act on it, and can be hidden or moved like every other card from the dashboard settings.

Contracts • A signing request that could not be delivered is now shown on the contract

When the email carrying a signing request bounces, the contract now says so: a notice at the top of the contract names the address and the date it bounced, the signer line and the contract list carry an Email bounced mark, and the Correct recipient email action sits right beside the notice. Until now the contract only read Sent and the bounce was visible on the Email delivery settings page alone, so a contract could wait for a signature the signer had never received. Automatic reminders no longer try an address that is known to bounce; correcting the address resends the request.