8deaf8513ba831197005ef530393edb07db8e5ff
The assign dropdown was empty on open. Two faults compounded: riders were queried by tenantid, and the source list defaulted to a tab that could never match. /partners/getriders returns nothing for any tenant, because a rider record leaves app_users.tenantid unset — riders belong to a partner and an app-location. Scoping by applocationid returns them, so both Orders and Deliveries now take the app-location from the rows they are showing and fall back to the caller's. The second fault was the "Store Fleet" default, which filtered for partnerid === 0. Every on-duty rider has a partnerid, so the default tab was always empty even once the query returned rows. It is now On Duty / This Partner, the latter enabled only when the orders name a partner. Dropped the getallusers?roleid=5 "own fleet" list it merged in. There is no rider role: app_roles defines 1-6 as Super admin / Operations / Admin / Manager per configid, and riders are identified by configid=6 inside getriders. roleid=5 matched a single user with two deliveries in the platform's history, while the users actually driving deliveries carry roleid 0. /partners/getriders is already a presence query rather than a roster — it requires status Active, onduty=1 and a riderlog dated today with logstatus=0 — so the list is riders working right now, and it carries the userfcmtoken needed to reach them. Added a refetch so someone logging off mid-shift drops out of the list. Riders are now notified. The push runs after the write and is reported separately: the deliveries are committed by then, so a failed push must not read as a failed assignment, but it must still be visible because a rider who was never told has work sitting unseen. A missing token is reported as a rider with no device registered rather than as a transport failure, since the remedy is different. Deliveries gains the rider actions its placeholder promised: change rider, notify, and send-cancellation carrying data.type=cancel. Change-rider is offered only while a delivery is pending, accepted or arrived, because reassigning resets orderstatus to pending and would otherwise rewind a journey already completed. reassignDeliveries was posting to /riders/reassigndeliveries, which is not registered on the backend and answers 404. It had no callers, so the failure had never been observed. It now goes through updatedelivery, one call per delivery, tolerating partial failure. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Run and deploy your AI Studio app
This contains everything you need to run your app locally.
View your app in AI Studio: https://ai.studio/apps/0406e53f-aca4-4047-80a3-dbe279cebc0b
Run Locally
Prerequisites: Node.js
- Install dependencies:
npm install - Set the
GEMINI_API_KEYin .env.local to your Gemini API key - Run the app:
npm run dev
Description
Languages
TypeScript
79.9%
CSS
19.4%
JavaScript
0.6%
