Order Detail View

Free — GPL coresize Lplanned, not built

Generated from docs/plan/core/order-detail-view/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Merchants need a unified view of complete order information (items, addresses, payment, customer) in one place. This feature provides a rich, readable order detail page in the admin.

The problem

I have to cross-reference multiple screens to see what a customer ordered, where it ships to, how they paid, and if they’re a repeat customer. One place showing everything would save 5 minutes per order.

What it does

• Display order header: order ID, date, customer name, email, phone
• Show order line items: product name, SKU, quantity, unit price, total per line
• Display order totals: subtotal, tax (if calculated), shipping, discount/coupon applied, total
• Show addresses: billing and shipping separately, flagged if different
• Display payment info: method (card/PayPal/etc), status (paid/pending/failed), transaction ID, authorization/capture dates
• Show customer profile card: is repeat customer, total lifetime spend, previous order count, loyalty tier if applicable
• Display fulfillment state: order status, shipment status, expected ship date, tracking numbers (when shipment-management shipped)
• Show order notes and tags (from order-notes, order-tags features)

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Order editing after checkout (changing items, quantities, prices) — that is a separate order-modification system with reconciliation complexity; out of scope for v1
• Real-time chat with customer from order detail — that is helpdesk integration, separate feature
• Predictive analytics (e.g., churn risk, upsell recommendations) — that requires ML; defer to plugin

Data model

No new schema; order-detail-view reads from existing orders, order_items, customers, payments collections. Aggregates data for display only.

API

• GET /api/admin/orders/:orderId — fetch full order with all related data
• GET /api/admin/orders/:orderId/timeline — fetch order history (deprecated by order-timeline, but keep for compatibility)

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Admin panel shows ‘Orders’ > ‘Order #12345’ detail page. Left column: order status, payment status, fulfillment status with badges. Center column: line items table, order totals, addresses card. Right column: customer card (name, email, repeat customer indicator, lifetime spend), order notes, tags. Bottom: timeline of state changes.

The seam — why this is core

Core owns order detail UI and aggregation logic. No paid seam — viewing order data is basic admin infrastructure.

Core owns the interface + honest order viewer; order management is core infrastructure, not a per-country obligation or credential.

Dependencies

• Existing orders collection schema
• order_items collection
• customers collection
• payments collection
• existing admin dashboard infrastructure

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• Fetch an order and confirm all line items, totals, addresses, and payment info are displayed correctly
• Verify repeat customer badge appears for customer with >1 order
• Confirm order status, payment status, and fulfillment status badges show correct values
• Verify order notes and tags (if order-notes/order-tags are implemented) appear on detail page
• Confirm page loads <2s for order with 50+ line items

Risks

Large orders (100+ items) can cause slow rendering if detail page fetches all line items synchronously. Implement lazy-loading or pagination for line items. Customer profile card (lifetime spend, repeat status) requires aggregation query; optimize with pre-calculated customer summary fields.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.