V2.0 User Categories, Access Control and Themes
Version 2.0 - User Tiers, Access Control, Themes
Requested:
Good it is time for next version upgrade
Make it 2.0
In this version I Plan to introduce various categories of users
1.) Admin and developers 2.) Power user(These people would Evaluate the product) 3.) Paid user(user who paid some amount for services we offer it may have many Plan based on that feather enabled)
4.) Free users(users who have given their identity with app(Like email and mobile no)
5.) open to all (some modules can be viewed by all visitors )
considering above information we have design user profile with registration (for First time user Just Email verification is enough and for Power users and paid user mobile no verification is mandatory)
Since it is app related to Trading activities I want maintain separate Database for user level setting (suggest a good name) and Table Structures
Enhancements
1.)Only Asset allocation page would be visible for all Rest of all Pages should come user admin and developers
So Design dashboard as per that
2.) though current UI and Color theme OK I want to have more lucrative UI Themes so users cal select current Theme(Pls make at least 3 to themes)
Save this Prompts in Prompt by project leader Section
and document every thing what you done in developer section documentation(as of now we don't have any end user and product documentation
Pls design such way that The Plan only designed by me my Team would do Patch working process also give Implementation plan for them in developer section documentation
Decisions taken
Four design questions were put to the project leader before planning. The answers below are binding for v2.0.
| Question | Decision | Reasoning |
|---|---|---|
How to isolate user data from tedb? | Separate Postgres database teudb | True blast-radius isolation. The market-data pipelines routinely do bulk deletes (deleteadateabove()) and full restores on tedb; user identities must never ride along with that. |
| How to carry the auth token? | JWT access (15 min) + refresh in localStorage | Works with the existing VPS CORS policy (allow_origins=["*"], no cookies). Smallest change from the current zero-interceptor axios setup. |
| How to deliver email links and mobile OTPs? | Pluggable Notifier, console stub in v2.0 | The full flow is buildable and testable now. Real SMTP and an Indian DLT-registered SMS sender drop in later without touching auth logic. |
| How many themes? | Four: Midnight, Deep Ocean, Carbon Amber, Daylight | Daylight is a real light theme and requires a de-hardcoding sweep of ~234 Tailwind classes across 17 files. |
| How to model paid plans? | Plans x feature-flag entitlements | Moving a feature between tiers becomes a DB row change, not a code deploy - which matters because the team patches, it does not redesign. |
| What about Asset Allocation? | Deferred - public "Under Construction" page | The AA feature is currently broken end to end (see below) and its equity return series was never loaded. Rebuilding it is out of scope for v2.0. |
Blockers discovered during design
Three pre-existing defects were found while exploring the codebase. They are folded into the patch sequence as Phase 0 because a release that introduces user accounts must not ship on top of them.
| Finding | Location | Impact |
|---|---|---|
| Backend cannot start | app/api/aa_routes.py:19 imports AnnualReturn, retired by migration 95e95ed1bbaa. main.py imports every router at module level. | ImportError kills the entire FastAPI app, not just the AA feature. AA/CLAUDE.md rule 4b says this router should be commented out; on the Strategies branch it is not. |
| Arbitrary file read | app/api/strategy_builder.py:118-122 accepts a client-supplied filePath and reads it with no path confinement. | Currently reachable with no authentication at all. |
| Credentials in logs | nseeod/pgs.py:24-27 and :55-58 print DB_PASS in cleartext on every connection open. | Passwords land in whatever captures backend stdout. |
Implementation
The design is decomposed into 20 patches across 5 phases, each independently assignable with explicit dependencies, acceptance criteria and a verification step. The application boots after every patch.
Full detail lives in the developer section:
- V2.0 Implementation Plan - the team's working document, all 20 patches
- User System Design - categories, verification rules, entitlement resolution
- Theme System - the four palettes and the de-hardcoding sweep
- User DB (teudb) Overview - full DDL for all 10 tables
Answering "suggest a good name"
The user database is named teudb - TradeEntry User DB. It sits alongside the existing tedb on the same Postgres server, follows the same four-letter convention, and reads unambiguously in env vars (LOCAL_UDB_NAME, VPS_UDB_NAME) and in backup scripts.
Its tables use the usr_ prefix, consistent with the repo's existing domain prefixes: scr_ for instrument registries, st_ for strategy tracking, te_ for generic time-series.
Status
| Item | Status |
|---|---|
| Prompt archived in this section | Done |
Five user categories designed (+ ANON pseudo-category) | Done |
teudb name chosen and justified | Done |
| 10 table structures with constraints and indexes | Done |
| Differential verification rule enforced at schema level | Done |
| Plan x feature entitlement model | Done |
| Access control design (only Asset Allocation public) | Done |
| Four themes specified with full palettes | Done |
| 20-patch implementation plan for the team | Done |
| Developer documentation written | Done |
| End-user documentation restructured | Done |
| Patch 0-19 execution | Pending - team |