Skip to content

Orders (Admin)

Orders provides list (tabs, search, filters, pagination) and detail with status updates and receipt flows. Access is gated by admin modules and zone like other dashboard areas.


GoalsNon-goals
Operate order pipeline from head officeReplicate POS lane timing or terminal UX
Link to technical order/payment docs where relevantDocument every legacy order state code

  • Routes: /dashboard/orders and /dashboard/orders/:id per table below.
  • Backend enforces zone and permissions; empty lists may mean no data in zone.

  1. Open Orders → filter tab → find order.
  2. Open detail → review lines, customer, payment state.
  3. Update status / actions per policy → confirm in list.

  • PII (customer contact) — follow data handling policy; restrict exports.
  • Payment disputes: correlate with POS payments & webhooks and PSP tools.

IDScenarioExpected
O1List loadsTabs and pagination work
O2Open detailMatches backend truth
O3Status changePersists; audit if available

PathPurpose
/dashboard/ordersOrder list with tabs, search, filters, pagination
/dashboard/orders/:idOrder detail, status update, receipt

The list is grouped by tab (server-side semantics):

TabRole
AllEvery order in scope
PaidPaid-related subset
PendingNot yet completed / awaiting action
CancelledCancelled orders
ReturnsReturn-related subset

Types align with AdminOrdersTab in admin-orders.api.ts.

  • Search — debounced text search across orders (400ms debounce).
  • Filters (popover) — vendor, store, date from / to, and sort (for example newest / oldest, amount, id). Choosing a store takes precedence for overview stats; vendor is used when no store filter is set.
  • Pagination — fixed page size (10 rows per page); changing tab, search, or filters resets to page 1.

Stat cards above the table reflect total orders, pending, completed, and refunded counts, scoped by the active store or vendor filter when set.

Columns include order id, customer, amounts, status labels, line counts, and actions (open detail). Column-level sort can sync back into list sort parameters.

  • Loads a single order via the admin orders API.
  • Shows lines, customer, store snapshot, totals, payment and order status, refund summary when present.
  • Edit order — modal to adjust allowed fields (including order status from the normalized option set used in the app).
  • Receipt — opens a POS-style receipt dialog for printing or review (PosOrderReceiptDialog), built from admin order data. Server HTML is GET /admin/orders/:id/receipt-html; optional query tip_signature=1 matches the vendor receipt merchant-copy layout (tip suggestions + signature + Merchant Copy footer). The receipt preview modal includes a checkbox to load that variant.

Statuses in the UI map from raw API strings to translated labels (including aliases like canceled → cancelled).

Vendor-side refunds and finance flows may overlap conceptually with Finance; the admin app focuses on oversight and status management.