David/WFDASH-WEBAPP
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
WFDASH-WEBAPP/public/manifest-rep.json

26 lines
577 B
JSON
Raw Normal View History

feat(rep): visit check-in PWA — phone GPS, offline outbox The rep app: open it on site, it finds who's around you, tick who you saw, done. Third instance of the per-route-group PWA pattern already running here (/m boss phone, /counter), so it reuses MobileAuthGate and gets its own manifest + service worker. Phone GPS is the primary position source, not the vehicle tracker. The tracker knows where the bakkie is; the phone knows where the rep is, and those diverge by a few hundred metres once the rep walks into the plant. GPS also needs no network, which matters because mine shafts have poor signal. The tracker is the secondary path (GET /api/v1/visits/position) for when location is denied or unavailable. The independently-collected vehicle trail corroborates check-ins afterwards, so honesty doesn't depend on the phone. Matching runs on the phone, not the server. The app caches a compact customer snapshot and runs rankNearbyCustomers locally, so there's one code path that behaves identically online and off — rather than a server path plus an offline fallback that only gets exercised in the places it's hardest to debug. - (rep)/rep/ layout, page, check-in view, outbox - visits-service.ts getCustomerSnapshot, recordVisits - POST /api/v1/visits record a check-in - GET /api/v1/visits/customers snapshot for the offline cache - GET /api/v1/visits/position tracker fallback - public/manifest-rep.json, public/sw-rep.js, pickSwPath() branch These routes authenticate with the browser session, not AGENT_API_KEY — the caller is a logged-in rep. The rep id comes from the validated session rather than the request body, so a client can't log a visit as someone else. The outbox uses localStorage rather than IndexedDB deliberately: the payloads are tiny and localStorage is synchronous, which matters when the rep hits Save and immediately pockets the phone. Entries are only removed once the server acknowledges them, so a failed flush retries instead of dropping a visit — duplicates are preferred over loss, and surfaced rather than merged. Permanently-rejected entries (4xx other than 401/408/429) are dropped so one bad row can't wedge the queue. recordVisits writes each visit independently: a stale customer id shouldn't cost the other four visits in a queued batch. BLOCKED until one PB admin change: rep_visits.position_source does not yet allow "phone" — verified against the live instance, PB returns 400 "Invalid value phone". Add it to the select. Separately, accuracy_m is silently accepted and discarded (PB ignores unknown fields), so GPS accuracy is thrown away until that number field is added; not blocking. 47 new tests. Verified on :4001: /rep serves 200 with the right metadata, manifest-rep.json and sw-rep.js are served. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-06 19:09:27 +00:00
{
"name": "WFDASH — Rep Visits",
"short_name": "Visits",
"description": "Log customer visits on site. Works without signal.",
"start_url": "/rep",
"scope": "/rep",
"display": "standalone",
"orientation": "portrait",
"background_color": "#FDF6F5",
"theme_color": "#E85D4C",
"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"
}
]
}
Reference in a new issue Copy permalink