You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit cfae0e6
Browse filesBrowse the repository at this point in the historyBrowse files
fix(dashboard): delivery routes are searched, sorted, paged and summarised by the database
The Delivery Routes page read the 500 most recently active routes and did
everything in the browser, so an older route could not be found, edited or
deleted from it, and its cards (routes, linked couriers, stops, distance,
active in 24h) counted those 500.
GET /api/dashboard/commerce/delivery-routes now takes q, sort, direction,
page and per_page, refuses a bad value with a 422, and answers one page with
how many routes match and a summary of every route. Search covers the id,
the recorded courier and the linked courier's name, the vehicle, and the
stops, time and distance as text, ignoring case, with LIKE wildcards
escaped. The default order is most recently active first, `last_active`
compared as text: Unix milliseconds and seconds from different seconds
already compare that way in time order. Ties read most recently active
first, then by id. Couriers are read by exactly the ids the page references.
"Active in 24h" uses the overview's window (40738ed) and its exact cut.
The page client is shared now. useServerList (functions/dashboard-list.ts)
is the request counter, page, page size, header sort and search debounce
that the Orders, Payments, Products, Gift Cards, Reviews and waitlist pages
each wrote by hand: only the newest answer lands, a search or filter change
asks for page 1, and a header the server cannot sort by returns to the
default order. The routes page uses it, keeps useRecordsDashboard for the
dialog and the delete confirmation, and reloads the page after a save or
delete instead of patching a local copy.
The endpoint used to return a bare array, which the auto-imported
useDeliveryRoutes().fetchDeliveryRoutes read as "every route".
createDashboardResource takes `paged: true` for it, and fetchAll then reads
every page through readEveryPage, so it returns every route rather than the
first 500.
Tested on SQLite, PostgreSQL and MySQL with 520 routes and couriers, every
fiftieth stored as Unix seconds. Controls went red: reading the first 500
couriers ("DeliveryRoute 4 references missing Courier 505"), dropping
useServerList's newest-answer guard, and dropping readEveryPage's
count-reached stop. A control that removed padding seconds to milliseconds
stayed green; the padding did nothing, so it is gone and the comment says why.
Not verified live: the dev database's delivery_routes has no courier_id and
there is no couriers table, so this endpoint answers 503 there, as the page
did before, which loaded couriers and failed on them.
Refs #3218
0 commit comments