coopcloud_code/projectmycelium_marketplace

Archived

Fork 0

Fix order history to use OrderManager trait via ServiceProvider #15

New issue

Closed

opened 2026-02-09 21:04:29 +00:00 by mik-tf · 3 comments

mik-tf commented

2026-02-09 21:04:29 +00:00

Owner

Problem

The order history page is completely empty. Order-related handlers bypass ServiceProvider and use fixture-based order services.

Affected Areas

Order history page (dashboard)
Order detail view
Order status tracking
Purchase flow completion

Current State

The hero OrderManager implementation exists at src/services/impl_hero/order_manager.rs (297 lines) with full CRUD via hero_osis network domain. The seed script creates 6 orders with various statuses (pending, confirmed, completed, cancelled).

Solution

Replace order fixture instantiation with services.orders.* calls
Wire order list page to services.orders.get_orders(&user_id)
Wire order detail to services.orders.get_order(&order_id)
Ensure order creation flow uses services.orders.create_order()
Verify status transitions work through trait methods

Acceptance Criteria

Order history shows 6 seeded orders
Order detail pages load correctly
Order status is displayed accurately
Zero fixture bypasses for order operations

Dependencies

Depends on: #9 (split dashboard.rs)
Independent of provider rewiring issues

## Problem The order history page is completely empty. Order-related handlers bypass ServiceProvider and use fixture-based order services. ## Affected Areas - Order history page (dashboard) - Order detail view - Order status tracking - Purchase flow completion ## Current State The hero `OrderManager` implementation exists at `src/services/impl_hero/order_manager.rs` (297 lines) with full CRUD via hero_osis network domain. The seed script creates 6 orders with various statuses (pending, confirmed, completed, cancelled). ## Solution 1. Replace order fixture instantiation with `services.orders.*` calls 2. Wire order list page to `services.orders.get_orders(&user_id)` 3. Wire order detail to `services.orders.get_order(&order_id)` 4. Ensure order creation flow uses `services.orders.create_order()` 5. Verify status transitions work through trait methods ## Acceptance Criteria - [ ] Order history shows 6 seeded orders - [ ] Order detail pages load correctly - [ ] Order status is displayed accurately - [ ] Zero fixture bypasses for order operations ## Dependencies - Depends on: #9 (split dashboard.rs) - Independent of provider rewiring issues

mik-tf added this to the Phase 1 — OSIS Production Ready milestone

2026-02-09 21:04:29 +00:00

mik-tf added the

bug

backend

phase-1

labels

2026-02-09 21:04:29 +00:00

mik-tf commented

2026-02-09 21:52:11 +00:00

Author

Owner

Order handlers fully use services.orders.* and services.cart.* — no fixture bypasses.

mik-tf commented

2026-02-09 22:54:25 +00:00

Author

Owner

Reopened — remaining work

Remaining bypasses in order.rs:

9x CurrencyService::new() (utility, keep)

These are pure exchange-rate conversions for price display — no trait needed. May close if we classify CurrencyService as legitimate utility.

## Reopened — remaining work Remaining bypasses in order.rs: - 9x `CurrencyService::new()` (utility, keep) These are pure exchange-rate conversions for price display — no trait needed. May close if we classify CurrencyService as legitimate utility.

mik-tf referenced this issue

2026-02-09 22:54:26 +00:00

End-to-end verification and seed data completeness #17

mik-tf referenced this issue from a commit

2026-02-10 01:03:09 +00:00

Fix issues #14, #15, #16: wallet, orders, services page

mik-tf referenced this issue

2026-02-10 02:26:24 +00:00

End-to-end verification and seed data completeness #17

mik-tf commented

2026-04-22 12:01:30 +00:00

Author