Statuses and workflow
The seven built-in statuses, which moves between them are allowed, and how that is enforced.
There are seven statuses and they are built in. You cannot add, rename or remove one. What you can control is the movement between them, and the messages sent when a ticket moves.
The seven statuses
| Status | Means |
|---|---|
| Received | Booked in at the counter. The starting status for every ticket. |
| Diagnosing | A technician is working out what is wrong. |
| In Progress | The repair is being carried out. |
| Waiting Parts | Held while a part is on order. |
| Ready | Work finished, waiting for the customer. |
| Collected | Handed back to the customer. |
| Paid | Settled. The end of the line. |
RepairModule.tsx (ALLOWED_NEXT_STATUSES, STATUS_STYLES) and repairs.module.css, mirroring VALID_TRANSITIONS in /api/repairs/[id].Which moves are allowed
Not every status can follow every other. The permitted moves are:
| From | Can move to |
|---|---|
| Received | Diagnosing |
| Diagnosing | In Progress, or back to Received |
| In Progress | Waiting Parts, Ready |
| Waiting Parts | In Progress, Ready |
| Ready | Collected, Paid |
| Collected | Paid |
| Paid | — (final) |
The rule is enforced on the server, not just in the interface. An attempt to jump from Received straight to Paid is rejected. The ticket screen only offers the moves that are actually legal, so the invalid ones are not presented in the first place.
The one-click next step
Each status has a natural next one — Received → Diagnosing, Diagnosing → In Progress, In Progress → Ready, Waiting Parts → In Progress, Ready → Collected — so the common path is a single action rather than a menu.