updates on the api integration and the design changes on the whole website

This commit is contained in:
2026-08-11 11:18:40 +05:30
parent d144ff71a9
commit bf28249528
48 changed files with 2888 additions and 6361 deletions

View File

@@ -328,7 +328,6 @@ const Preview = () => {
const deliveryData = stateData.deliveryData || [];
const autoRiders = stateData.autoRiders || [];
const absentRidersPayload = stateData.absentRidersPayload || [];
const rider = stateData.rider || null;
const appId = useMemo(() => {
if (stateData.appId) return stateData.appId;
@@ -409,11 +408,34 @@ const Preview = () => {
});
const createFinalDeliveryMutation = useMutation({
// finalCreatedeliveries now assigns each order directly on Doormile's
// own booking record (POST /admin/bookings/:id/assign-miler per order,
// resolved internally) instead of posting to jupiter — see api.js for
// why: jupiter's createdeliveries wrote into jupiter's own orphaned
// database, which neither the Orders "pending" list nor the Deliveries
// "dispatched" filter ever read (both come from GET /admin/bookings).
mutationFn: finalCreatedeliveries,
onSuccess: () => {
OpenToast('Delivery Created Successfully', 'success', 2000);
setIsLoading(false);
if (rider?.userfcmtoken) notifyRiderMutation.mutate(rider.userfcmtoken);
// stateData.rider (a single rider forwarded via navigate() from the
// Orders page) is never actually populated in the real flow — that
// page's navigate() call doesn't include a `rider` key at all — so
// this was a permanent no-op and no rider ever got notified after
// assignment. Notify every rider actually present in the committed
// list instead. notifyRider expects a milerprofileid (not an FCM
// token — the server looks the device up itself); rider_id/userid
// here is the id this page already treats as canonical throughout
// (see flattenRiders/moveOrderInPreviewData above) since it's the
// only rider identifier the solver echoes back — unconfirmed whether
// that's actually a milerprofileid by the time it reaches here.
const notifiedRiderIds = new Set();
finaldeliveryList.forEach((order) => {
const riderId = order.rider_id ?? order.userid;
if (riderId == null || notifiedRiderIds.has(String(riderId))) return;
notifiedRiderIds.add(String(riderId));
notifyRiderMutation.mutate(riderId);
});
navigate('/doormile/deliveries');
},
onError: (error) => {
@@ -479,6 +501,18 @@ const Preview = () => {
OpenToast('No deliveries to assign', 'error', 3000);
return;
}
// "Change Rider" and "Reconcile" were two independent buttons with
// nothing linking them — an operator could edit a rider's steps and hit
// Assign Orders without ever pressing Reconcile. Committing stale step
// ordering corrupts route sequences server-side (see this folder's
// CLAUDE.md §3, called out as the single biggest production risk here).
// dirtyRiderIds only ever holds riders edited since the last successful
// reconcile of that specific rider, so size > 0 means real unreconciled
// edits are pending.
if (dirtyRiderIds.size > 0) {
OpenToast(`Reconcile ${dirtyRiderIds.size} edited rider(s) before assigning`, 'warning', 4000);
return;
}
setIsLoading(true);
createFinalDeliveryMutation.mutate({ deliveries: finaldeliveryList });
};
@@ -789,9 +823,18 @@ const Preview = () => {
>
Back
</Button>
<Button variant="contained" fullWidth={isMobile} onClick={handleFinalCreateDelivery}>
Assign Orders
</Button>
<Tooltip title={dirtyRiderIds.size > 0 ? `Reconcile ${dirtyRiderIds.size} edited rider(s) first` : ''}>
<span style={isMobile ? { width: '100%' } : undefined}>
<Button
variant="contained"
fullWidth={isMobile}
disabled={dirtyRiderIds.size > 0}
onClick={handleFinalCreateDelivery}
>
Assign Orders
</Button>
</span>
</Tooltip>
</Stack>
</Box>