[Bug]: Recent orders widget shows zero order amounts

[roncodes]

Summary

The Storefront recent orders widget always shows 0 in the order amount column because the widget renders order.meta.total, but the internal orders list response appears to come from the FleetOps index order resource, which does not include Storefront checkout totals in meta.

Current Behavior

The recent orders widget loads orders with:

GET storefront/int/v1/orders

from addon/components/widget/orders.js, then renders the table amount with:

{{format-currency order.meta.total order.meta.currency}}

from addon/components/widget/orders.hbs.

The displayed amount is always 0/empty. Research points to the backend response shape as the likely source:

• Storefront registers internal orders through fleetbaseRoutes('orders') in server/src/routes.php.
• Fleetbase\Storefront\Http\Controllers\OrderController extends the FleetOps internal order controller.
• FleetOps internal order controller defines an $indexResource for list responses.
• The generic query path uses $indexResource for collection responses.
• FleetOps' index order resource returns meta as only ['_index_resource' => true], so Storefront-specific meta.total, meta.subtotal, and meta.currency are not present in the recent-orders list payload.

This means the widget is asking for the correct Storefront checkout total field, but the list API response no longer carries the required Storefront order total data.

Expected Behavior

The recent orders widget should show the correct Storefront order total and currency for every order.

The amount column should continue to render through the {{format-currency}} helper using a numeric total and currency code from the order response, for example:

{{format-currency order.meta.total order.meta.currency}}

or an equivalent Storefront-specific response field if the backend intentionally exposes totals outside meta.

Steps to Reproduce

1. Create or find a Storefront order with a non-zero checkout total.
2. Open the Storefront home dashboard / recent orders widget.
3. Observe the order amount column in the recent orders table.
4. Compare the displayed amount to the checkout/order total stored for the Storefront order.

Affected Area

• Recent orders widget: addon/components/widget/orders.js
• Recent orders widget template: addon/components/widget/orders.hbs
• Internal Storefront orders API: storefront/int/v1/orders
• Storefront internal order controller: server/src/Http/Controllers/OrderController.php
• Storefront order filter: server/src/Http/Filter/OrderFilter.php
• FleetOps internal order list/index resource currently used by inherited query behavior

Proposed Fix

Fix the response shape feeding the Storefront recent orders widget so Storefront order totals are included reliably.

Recommended direction:

• Add a Storefront-owned internal orders list response or resource for storefront/int/v1/orders instead of relying directly on the FleetOps order index resource.
• Ensure the list response includes Storefront checkout totals and currency, either under meta.total / meta.currency for compatibility with existing Storefront UI or as a clearly named Storefront amount field paired with a frontend update.
• Preserve the existing Storefront filtering behavior: current company, meta->storefront_id, payload relationships, tracking number/status requirements, active-store filter, sort, limit, and status filter.
• Keep the recent orders widget amount rendered through {{format-currency}}.
• Review related Storefront order views that also read order.meta.total, including customer/order panels, so the fix does not only patch the home widget while leaving the same broken response shape elsewhere.

Avoid fixing this only by switching the widget to transaction_amount: FleetOps transaction amounts can be zero for orders created without a paid transaction, while Storefront checkout totals are stored in Storefront order metadata during checkout capture.

Acceptance Criteria

• Recent orders widget amount column shows the correct non-zero Storefront order total.
• Recent orders widget uses {{format-currency}} with the correct currency code.
• The widget total row sums the same displayed Storefront totals correctly.
• Storefront internal orders list responses include the fields required by Storefront UI for totals.
• The fix does not regress FleetOps order list behavior.
• Coverage or manual verification includes at least one paid delivery order and one pickup order when possible.
• Frontend lint/tests and relevant backend tests are run, or skipped validation is explained.

Documentation Impact

No public documentation update appears required unless the API response contract for Storefront internal orders is intentionally documented.

API Reference Impact

This affects an internal console API response shape, not the public Storefront API. No fleetbase/postman update appears required unless the internal Storefront orders endpoint is covered there.

[github-actions]

Triage comment:

I understand this as a Storefront internal orders list serialization bug. The UI already reads Storefront checkout totals from order.meta.total / order.meta.currency, but GET storefront/int/v1/orders appears to return an order collection shape that does not preserve those Storefront metadata fields.

Repository inspection supports the backend-focused direction:

• server/src/routes.php registers internal orders with fleetbaseRoutes('orders').
• server/src/Http/Controllers/OrderController.php extends the FleetOps internal order controller and only overrides the filter/actions.
• ../core-api/src/Traits/HasApiControllerBehavior.php uses $indexResource ?? $resource for collection responses.
• Storefront checkout capture writes subtotal, delivery_fee, total, currency, and is_pickup into order meta in server/src/Http/Controllers/v1/CheckoutController.php.
• The recent orders widget, full orders table, customer panel orders, and order summary views all consume order.meta.total and related fields.

Likely affected Storefront areas:

• server/src/Http/Controllers/OrderController.php
• server/src/Http/Filter/OrderFilter.php
• possibly a new server/src/Http/Resources/... Storefront-owned order index/list resource
• addon/components/widget/orders.js
• addon/components/widget/orders.hbs
• related consumers in addon/controllers/orders/index.js, addon/components/customer-panel/orders.hbs, and order summary/panel templates

This looks safe for agent implementation if kept to a small Storefront-owned internal list response fix. I would avoid changing FleetOps resources globally and avoid switching totals to transaction_amount, since checkout totals are already stored in Storefront order metadata and are used by multiple Storefront views.

Documentation impact for fleetbase/fleetbase.io: likely none if this remains an internal console API response correction. If the internal Storefront orders response is documented anywhere, note the restored/required meta.total, meta.subtotal, meta.delivery_fee, and meta.currency fields.

API reference impact for fleetbase/postman: likely none because this is an internal storefront/int/v1/orders console endpoint, not the public Storefront API. The implementing agent should still confirm whether postman covers this internal endpoint before finalizing.

Suggested validation:

• pnpm lint
• pnpm test:ember
• pnpm build
• composer test:lint
• composer test:types
• composer test:unit if backend resource/controller tests are added or existing backend tests cover this path
• manual/API verification of GET storefront/int/v1/orders?storefront=<store>&limit=14&sort=-created_at for at least one paid delivery order and one pickup order, confirming non-zero totals and currency in the response and widget total row

Blocking questions: none at this point, assuming the intended compatibility target is to keep totals under order.meta.* for Storefront internal order list responses.

AGENT_STATUS: ready_for_approval