Dashboard home was hardcoding fake numbers (2,431/10,000 requests, fake "Pro Plan", fake activity log, fake random bar chart) despite the real analytics/logs/keys endpoints already existing and being used correctly elsewhere (Usage, Logs, Tokens pages). A fresh account with zero real activity was showing 24% "used" from nobody's data. Rewired every stat card, the usage chart, and the activity table to real /api/analytics/*, /api/logs, and /api/keys data. Every Quick Action now does something real (navigate to the real page, or call a real endpoint) instead of being a no-op or hardcoded button. Also removed 5 sidebar/footer links (AI Setup Guides, Tools & Permissions, Billing, Team, Settings, Support) that pointed at nonexistent routes or pages with no backend feature behind them at all — no team/multi-user system, no per-tool permission toggles, no real subscription/billing system exist in the backend yet. Documented what's needed to build each one for real in FUTURE_FEATURES.md rather than shipping more fake UI. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
84 lines
3.8 KiB
Markdown
84 lines
3.8 KiB
Markdown
# Removed / Not-Yet-Built Features
|
|
|
|
These sidebar pages were removed from `src/pages/dashboard/DashboardLayout.tsx`'s
|
|
nav because no backend feature exists for them — they were showing fully
|
|
hardcoded mock data with no real API behind them. Removed rather than shipped
|
|
with fake data, per the "no mock data" rule.
|
|
|
|
## 1. Billing / Subscriptions
|
|
|
|
**Was at:** `/dashboard/billing` (deleted: `src/pages/dashboard/Billing.tsx`)
|
|
|
|
**What it showed (all fake):** hardcoded "Pro Plan $49/month", 3-tier plan
|
|
comparison cards, fake invoice history table.
|
|
|
|
**What's needed to rebuild for real:**
|
|
- Backend: `plan`, `subscription_status`, `stripe_customer_id` columns on
|
|
`users` table (mentioned as a possibility in `HANDOFF.md` from the original
|
|
handoff, never implemented)
|
|
- Real Stripe integration — the old Next.js frontend had
|
|
`src/app/api/stripe/{checkout,webhook}/route.ts` but they were dead code
|
|
(never called, placeholder keys, no backend wiring). Since Vite can't host
|
|
secret-key server logic, this needs to live as new endpoints on the FastAPI
|
|
backend (`Multi-Tenant-ODOO-MCP`), not the frontend.
|
|
- New endpoints: `POST /api/billing/checkout`, `POST /api/billing/webhook`,
|
|
`GET /api/billing/invoices`
|
|
- Frontend: rebuild the page against those real endpoints
|
|
|
|
## 2. Team / Multi-User Accounts
|
|
|
|
**Was at:** `/dashboard/team` (route never existed — dead nav link, 404)
|
|
|
|
**What's needed:** an entirely new multi-user-per-account concept. Currently
|
|
one `users` row = one account = one set of Odoo credentials/API keys. Team
|
|
support means either:
|
|
- A new `team_members` table linking multiple `users` rows to one billing
|
|
account with role-based permissions, or
|
|
- An `account_id` grouping concept above `users`
|
|
|
|
This is a significant schema/auth redesign, not a small addition.
|
|
|
|
## 3. Tools & Permissions
|
|
|
|
**Was at:** `/dashboard/tools` (route never existed — dead nav link, 404)
|
|
|
|
**What's needed:** per-user, per-tool enable/disable toggles for the 47 MCP
|
|
tools currently registered in `server.py`'s `TOOLS` list. Would need:
|
|
- A new `disabled_tools` table or JSON column on `users`
|
|
- A check in `call_tool()` (`server.py`) before dispatch: reject if the tool
|
|
is disabled for that user
|
|
- Frontend: a page listing all 47 tools grouped by module (connection,
|
|
discovery, records, workflow, smart) with toggles, calling a new
|
|
`PATCH /api/tools/{name}` endpoint
|
|
|
|
## 4. AI Setup Guides
|
|
|
|
**Was at:** `/dashboard/guides` (route never existed — dead nav link, 404)
|
|
|
|
**What's needed:** this is content, not really a backend feature — step-by-step
|
|
setup instructions for Claude, Codex, Cursor, Windsurf. Partially exists
|
|
already: `/dashboard/endpoints` already has a working Claude Desktop JSON
|
|
config generator with the real API key and MCP URL. This page could be built
|
|
as a pure frontend content page (no backend needed) with setup docs for the
|
|
other clients, following the same pattern already in `Endpoints.tsx`.
|
|
|
|
## 5. Settings (account settings / change password while logged in)
|
|
|
|
**Was at:** `/dashboard/settings` (route never existed — dead nav link, 404)
|
|
|
|
**What's needed:** currently the only way to change a password is the
|
|
forgot-password token-based flow (`/forgot-password` → `/reset-password`).
|
|
There's no "logged in, change my password" endpoint. Would need:
|
|
- Backend: `POST /api/account/change-password` (current password + new
|
|
password, no token needed since the user is already authenticated)
|
|
- Frontend: a settings page with that form, plus maybe email/display-name
|
|
fields if those become editable later
|
|
|
|
## 6. Support link
|
|
|
|
**Was at:** footer link `/dashboard/support` (route never existed — dead
|
|
link, removed entirely from `DashboardLayout.tsx`, not just hidden)
|
|
|
|
Trivial — just needs a real destination (mailto link, external help site, or
|
|
a real support-ticket feature) whenever there's something to point it at.
|