WFDASH-WEBAPP/src
SJCoetz 4535a20eee fix(buyer-tasks): mark-ready puts item into collection pool, not collected
When the operator clicks "Mark as ready" on a buyer-tasks po_sent card
and fills in the note, the item should land in the collection pool
(`item_status: "collection_pool"` + `ready_for_collection: true`) so
a driver can be assigned. Previously the service set
`item_status: "ready_delivery"`, which was rendered as the word
"Collected" on /orders and on /orders tabs — operators reasonably
read that as "driver already picked it up", and the item never
appeared on /collection-pool where they expected to assign a driver.

Now:
- markGroupReady writes a single PB update with the same shape as
  /api/v1/collection-map/items/[id]/assign (collection_pool +
  ready_for_collection: true + notes)
- po_sent buyer-tasks filter excludes collection_pool and assigned,
  so marked-ready items drop out of buyer-tasks and surface on
  /collection-pool instead
- ITEM_STATUS_VISUAL.ready_delivery is labelled "Ready for
  Collection" (kept distinct from the actual `collected` state) for
  any other flow that legitimately sets this status (e.g. stock-out)
- new item-status-ui.test.ts locks down the label/tab mapping so
  the regression can't return

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Co-authored-by: Orca <help@stably.ai>
2026-07-30 15:25:33 +02:00
..
app fix(orders-sprint): transition pending→processed, merge Unknown tabs, polish layout 2026-07-29 23:06:11 +02:00
components fix(buyer-tasks): generate PO succeeds + supplier stripe + PO badge 2026-07-30 15:00:18 +02:00
lib fix(buyer-tasks): mark-ready puts item into collection pool, not collected 2026-07-30 15:25:33 +02:00
styles feat(item-history): add getItemHistory service with 5 PB queries 2026-07-29 14:51:58 +02:00
test-setup.ts feat(buyer-tasks): group card with color-coded action button 2026-07-29 20:11:39 +02:00