updates on the ui changes and the bot changes

This commit is contained in:
2026-08-20 13:12:56 +05:30
parent e1cc874218
commit ce32465a6f
12 changed files with 567 additions and 25 deletions

View File

@@ -54,6 +54,14 @@ An opt-in "activity" date basis was added so an order booked yesterday and still
The filter field and the bucket field have to be the same field. If carried-over work needs to be visible on the board, it needs its own bucket ("Carried over") — not a time-of-day wave it does not belong to. Decide that before reaching for the date filter again.
### Picked is empty for hyperlocal traffic, and that is correct
`doormile-flow.md` §5: at `pickup-complete` the booking becomes a consignment, and **matching 3-digit pickup/delivery pincode prefixes go straight to `Out_for_Delivery`** (hyperlocal); everything else routes via a hub.
So a Coimbatore-to-Coimbatore order (641xxx → 641xxx) is picked up and is *immediately* out for delivery. It never rests in a "picked" state. The Picked tab reading 0 while orders are plainly moving is expected behaviour on hyperlocal traffic, not a missing mapping.
The confusing part is downstream of that: the booking's own `status` **freezes at `Converted_To_Consignment`** the moment it is picked up. The Deliveries page joins `GET /admin/consignments` and lets the consignment's status win, so a row correctly reads **Active** while `GET /admin/bookings` still says `Converted_To_Consignment`. That looks like a bug on inspection, which is why the status badge carries a tooltip naming the consignment and its status whenever the value came from there (`statusfromconsignment` on the row).
### ⛔ Never bucket on `assigntime`
It is **not** an assignment time. The Doormile bookings feed has no assignment timestamp, so `api.js` maps `assigntime` to the booking's `updatedat` — its last-modified column. Any status change, parcel scan, payment or pickup-complete re-stamps it.

View File

@@ -62,7 +62,12 @@
display: flex;
align-items: center;
justify-content: space-between;
padding: 0 24px;
/* Tighter on the LEFT than the right. The logo is the page's anchor and was
sitting 24px in; the right side keeps the wider gutter because the controls
there need clearance from the window edge. #strat-row below carries the
same asymmetry — the two are stacked, so their left edges have to agree or
the logo no longer lines up with the batch row under it. */
padding: 0 24px 0 12px;
background: var(--bg);
border-bottom: 1px solid var(--border);
z-index: 1010;
@@ -74,17 +79,29 @@
gap: 12px;
}
/* The badge is sized to the D ITSELF, not to the image file.
doormile-mark.png fills only 66.8% of its own canvas (alpha bounding box
170..853 of 1024) — a third of every edge is transparent padding. In the old
44px box that drew a 29px D with 7.3px of empty space on each side, so the
12px gap to "Dispatch" read as ~19px. That whitespace was the "large gap",
not the gap property.
The image is scaled 150% (1 / 0.668) to cancel the padding exactly, and
overflow clips what spills — which is only transparent pixels. Net effect:
the D stays the size it already looked, and the gap becomes a true 12px. */
.dispatch-container .logo-badge {
width: 44px;
height: 44px;
width: 30px;
height: 30px;
display: flex;
align-items: center;
justify-content: center;
overflow: hidden;
flex: 0 0 auto;
}
.dispatch-container .logo-badge-img {
width: 100%;
height: 100%;
width: 150%;
height: 150%;
max-width: none;
object-fit: contain;
}
@@ -287,7 +304,8 @@
display: flex;
align-items: center;
gap: 8px;
padding: 0 24px;
/* Same left gutter as #hdr — see the note there. */
padding: 0 24px 0 12px;
background: var(--bg);
border-bottom: 1px solid var(--border);
}