[HARD][DASHBOARD] Build fleet operations dashboard for vehicles, drivers, and contracts

[Obiajulu-gif]

Overview

Build an admin fleet operations dashboard for tracking vehicles, assigned drivers, active contracts, repayment performance, ownership progress, and operational status.

Problem

ChainMove is a mobility finance platform, so admins need a central dashboard for vehicle and contract operations. Without this, it is difficult to manage which driver has which vehicle, which contracts are active, and which assets are underperforming.

Expected solution

Create a fleet operations dashboard with:

• vehicle list/table
• driver assignment status
• active contract status
• repayment completion percentage
• vehicle availability/assigned/maintenance status
• filters by status, driver, contract, and date
• vehicle detail drawer/page
• key metrics cards
• empty/loading/error states

Advanced requirements

• Add safe backend aggregation where needed.
• Keep driver, vehicle, and contract data normalized where possible.
• Avoid duplicating calculation logic in multiple components.
• Make the UI scalable for many vehicles.

Files likely involved

• admin dashboard pages/components
• vehicle model/API routes
• driver/user model/API routes
• contract/repayment models
• fleet table and detail components
• dashboard metric cards

Acceptance criteria

• Admin can view fleet-level metrics.
• Admin can see vehicle assignment and contract status.
• Admin can filter and search fleet records.
• Vehicle detail view shows driver, contract, and repayment summary.
• Access is admin-only.
• Responsive UI is implemented.
• npm run lint and npm run build pass.

Suggested labels

dashboard, admin, fleet, operations, backend, frontend, hard

Difficulty

Hard

[ekwe7]

I would love to work on this issue. I have experience building production ready applications and collaborating through GitHub workflows. I'll carefully analyze the current implementation, propose a reliable solution, and submit a well-tested PR. My focus is on clean code, maintainability, and timely delivery

[ekwe7]

I would love to work on this issue. I have experience building production ready applications and collaborating through GitHub workflows. I'll carefully analyze the current implementation, propose a reliable solution, and submit a well-tested PR. My focus is on clean code, maintainability, and timely delivery

[dominiccreates]

Hello, I would love to resolve this issue
My ETA is 4hours

[tosin-zoffun]

The straightforward part of this is the table, the filters and the metric cards. The part that decides whether it holds up at scale is in the advanced requirements, and that's the part I'd focus on. I'm a full-stack engineer in Next.js, React and TypeScript with backend experience, so building both the fleet UI and the aggregation behind it is in my lane.

Three things I'd treat as the backbone:

Computation lives server-side. Fleet metrics and the repayment-completion percentages should be aggregated at the data layer, not by pulling every vehicle, driver and contract to the client and summing there. That keeps it efficient, avoids N+1 query patterns, and is what 'safe backend aggregation' and 'scalable for many vehicles' really require. The fleet table would be paginated with server-side filtering and search rather than loading the whole fleet and filtering in the browser, so it doesn't fall over once the fleet is large.

One source of truth for derived numbers. Repayment completion and ownership progress are money-derived figures, and on a finance platform they can't be recomputed independently in the table, the detail drawer and the metric card, or the three will eventually disagree. I'd put that logic in one shared place (a server function or selector) and have every view read from it, so the same vehicle shows the same number everywhere.

Normalized data, enforced access. Driver, vehicle and contract stay as related entities referenced by id rather than denormalized copies, and admin-only access is enforced on the API routes themselves, not just by hiding the dashboard route, since hiding the UI isn't access control.

On top of that backbone: the vehicle list with assignment and contract status, status/driver/contract/date filters, the vehicle detail view summarizing driver, contract and repayment, the key-metrics cards, and proper empty, loading and error states throughout, all responsive. I'll make sure npm run lint and npm run build pass clean before the PR.

This is competitive already, so I'd want to align with you on the aggregation approach up front, since that's the decision everything else hangs off. Please assign this one to me and I'll get started.

[grantfox-oss]

🦊 GrantFox — @tosin-zoffun has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #46)
2. Your PR will be reviewed by the Chainmove maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign campaign!

@tosin-zoffun's PR #54 was approved and merged by @Obiajulu-gif.

🏆 @tosin-zoffun: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (188 total points). Track your full progress on GrantFox.

👏 Great work, @tosin-zoffun! Keep contributing to Chainmove.