Dave
d98c263f45
Scan the QR printed on a delivery note, see what it is, and act on it: reprint, photograph the signed copy, or walk it toward invoicing. It is its own route group outside `(app)` so it gets a clean full-bleed layout and its own manifest — "add to home screen" should give the operator a scanner, not the CRM. Mirrors the pattern `(counter)` already uses. Two detectors, not one. `BarcodeDetector` is fast and allocation-free but is Chrome-only: Safari/iOS still has it "Under Consideration" (WebKit bug #254573) and Firefox does not ship it. A scanner that only used it would simply not work on an iPhone. So native where it exists, jsQR everywhere else — pure JS, so no 2 MB WASM payload on a weak warehouse signal, and the delivery-note QR is always a QR code. Both run against the same canvas frame so the caller never branches. Also requires HTTPS, which the page says plainly when it isn't. The QR carries the human number, so the first call is a new resolve endpoint mapping number -> PB id. Everything after that speaks ids, which is what every existing route already takes. The number is shape-validated before any network call, so a supplier's packing label can't fire a lookup. STATUS LADDER. mark-invoiced hard-refuses anything that isn't po_received, and customer-po refuses a note that isn't sent/loaded — so rather than offering a button that 500s, each action only appears when the server would accept it, and the card shows which step comes next. It routes draft -> loaded -> po_received -> invoiced via the existing load-dn, NOT draft -> sent, because draft -> sent means "create a quote and email it" and a warehouse scan must never trigger that silently. The signed-copy upload deliberately uses the upload-only endpoint, not /api/v1/deliveries/mark-signed-copy — that one flips the note to `completed` in the same write, which would jump a note straight past invoicing. Manual entry is always available, so the page works on a device with no camera or a browser that won't scan. Tests decode the REAL delivery-note QR through the production fallback path at print size, and assert the shape check rejects a supplier QR, a random string and an over-long number.
27 lines
731 B
JSON
27 lines
731 B
JSON
{
|
|
"name": "WFDASH Delivery Scanner",
|
|
"short_name": "DN Scanner",
|
|
"description": "Scan the QR on a delivery note to reprint it, capture the signed copy, or move it to ready to invoice",
|
|
"start_url": "/scan",
|
|
"scope": "/",
|
|
"display": "standalone",
|
|
"background_color": "#FFFFFF",
|
|
"theme_color": "#4C96D7",
|
|
"orientation": "portrait",
|
|
"icons": [
|
|
{
|
|
"src": "/android-chrome-192x192.png",
|
|
"sizes": "192x192",
|
|
"type": "image/png",
|
|
"purpose": "any"
|
|
},
|
|
{
|
|
"src": "/android-chrome-512x512.png",
|
|
"sizes": "512x512",
|
|
"type": "image/png",
|
|
"purpose": "any"
|
|
}
|
|
],
|
|
"categories": ["business", "productivity", "utilities"],
|
|
"prefer_related_applications": false
|
|
}
|