coopcloud_code/projectmycelium_marketplace

Archived

Fork 0

Rewire Service Provider handlers to use ServiceProvider traits #13

New issue

Closed

opened 2026-02-09 21:04:05 +00:00 by mik-tf · 2 comments

mik-tf commented

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

Owner

Problem

13 Service Provider handlers bypass ServiceProvider, causing empty service request lists, empty revenue charts, and missing SLA data when running with hero_osis backend.

Affected Handlers

Template-Rendering Handlers

service_provider_section — Main SP dashboard
service_provider_detail — Individual service view
service_provider_requests — Service request management
service_provider_request_detail — Individual request view
service_provider_revenue — Revenue analytics
service_provider_sla — SLA management
service_provider_settings — SP settings

API Handlers

service_provider_data_api — ✅ Already working (returns 4 services)
service_provider_requests_api — Service request list
service_provider_revenue_api — Revenue data
service_provider_sla_api — SLA metrics
service_provider_request_action_api — Accept/reject requests

Current State

The SP data API works (returns 4 services), but all template-rendering handlers and most other API handlers use:

let service = ServiceProviderService::builder().build();
let user_persistence = UserPersistence::new();

UserPersistence reads service requests from JSON files in the fixture data directory.

Solution

Replace ServiceProviderService::builder().build() with services.service_provider.*
Replace UserPersistence::new() calls with appropriate trait methods
Ensure service request CRUD operations go through hero_osis

Acceptance Criteria

SP dashboard shows real services with request counts
Service request list populated from hero_osis
Accept/reject actions work end-to-end
Revenue data displays correctly
SLA page shows agreement data
Zero fixture bypasses remain in SP handlers

Dependencies

Depends on: #9 (split dashboard.rs)
Can be done in parallel with: #10, #11, #12

## Problem 13 Service Provider handlers bypass ServiceProvider, causing empty service request lists, empty revenue charts, and missing SLA data when running with hero_osis backend. ## Affected Handlers ### Template-Rendering Handlers - `service_provider_section` — Main SP dashboard - `service_provider_detail` — Individual service view - `service_provider_requests` — Service request management - `service_provider_request_detail` — Individual request view - `service_provider_revenue` — Revenue analytics - `service_provider_sla` — SLA management - `service_provider_settings` — SP settings ### API Handlers - `service_provider_data_api` — ✅ Already working (returns 4 services) - `service_provider_requests_api` — Service request list - `service_provider_revenue_api` — Revenue data - `service_provider_sla_api` — SLA metrics - `service_provider_request_action_api` — Accept/reject requests ## Current State The SP data API works (returns 4 services), but all template-rendering handlers and most other API handlers use: ```rust let service = ServiceProviderService::builder().build(); let user_persistence = UserPersistence::new(); ``` `UserPersistence` reads service requests from JSON files in the fixture data directory. ## Solution 1. Replace `ServiceProviderService::builder().build()` with `services.service_provider.*` 2. Replace `UserPersistence::new()` calls with appropriate trait methods 3. Ensure service request CRUD operations go through hero_osis ## Acceptance Criteria - [ ] SP dashboard shows real services with request counts - [ ] Service request list populated from hero_osis - [ ] Accept/reject actions work end-to-end - [ ] Revenue data displays correctly - [ ] SLA page shows agreement data - [ ] Zero fixture bypasses remain in SP handlers ## Dependencies - Depends on: #9 (split dashboard.rs) - Can be done in parallel with: #10, #11, #12

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

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

mik-tf added the

backend

refactor

phase-1

labels

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

mik-tf commented

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

Author

Owner

Already mostly rewired. Added services param to 2 remaining handlers (commit 9e669d7).

Already mostly rewired. Added services param to 2 remaining handlers (commit 9e669d7).

mik-tf commented

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

Author

Owner

Reopened — remaining work

Remaining bypasses in dashboard/service_provider.rs:

7x UserPersistence calls: load/save_user_data, remove_service_request, update_service_request_progress, get_user_sla_by_id, add_user_product, get_user_products

Depends on #26 for new ServiceProviderManager trait methods.

## Reopened — remaining work Remaining bypasses in dashboard/service_provider.rs: - 7x `UserPersistence` calls: load/save_user_data, remove_service_request, update_service_request_progress, get_user_sla_by_id, add_user_product, get_user_products Depends on #26 for new ServiceProviderManager trait methods.

mik-tf referenced this issue

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

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

mik-tf closed this issue

2026-02-10 00:27:07 +00:00

Commenting is not possible because the repository is archived.