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>
