1. Purpose & Scope
The portal is the staff-only front door and connective tissue for TechToss's internal tools. It owns no domain data of its own — instead it provides the single login, the navigation, and the overview that individual apps can't give alone. Critically, it's built to grow: Inventory and Transactions are the first two apps to live under it, but the portal should treat "an app" as a general slot so future tools (reporting, refurbishment tracking, volunteer scheduling, whatever helps the workflow and tabulation) can be added with minimal friction.
This is also the shared authentication layer flagged in both prior outlines. Rather than each app inventing its own accounts, the portal handles login once and passes that identity to every app under it — designed a single time, reused by everything that plugs in.
2. Core Responsibilities
The portal is defined by function rather than a data model. Its main jobs:
- Authentication & single sign-on — one login granting access to every app according to the user's role.
- App launcher / navigation — a clear, extensible home that lists available apps and routes staff to them.
- Dashboard — a summary pulling key numbers from whichever apps are installed.
- User & role management — creating accounts, assigning roles, resetting passwords, centrally.
3. Key Design Principle: Extensibility
Because the point is future growth, this deserves to be a first-class concern rather than an afterthought:
- Treat each app as a plug-in "module." The portal keeps a registry of installed apps — each with a name, an icon/link, the roles allowed to use it, and optionally a summary widget it contributes to the dashboard. Adding a future app becomes "register a new module" rather than "rewrite the portal."
- Standardize how apps report to the portal. If every app exposes its summary numbers and its permission needs in the same shape, the dashboard and role system absorb new apps automatically. Deciding this contract early is what keeps the portal from calcifying around just Inventory and Transactions.
- Consistent shell. Shared navigation, login state, and styling live at the portal level so every current and future app feels like one system, not a pile of separate tools.
4. Key Features
App launcher / home
The landing page after login: the set of apps this staff member can access, presented as a simple, extensible list or grid. New apps appear here once registered.
Unified dashboard
The portal's main value beyond login — highlights from whatever apps are installed in one view. Today that's stock counts and items ready to move (Inventory) plus recent transactions and total dollars donated this period (Transactions). Because it's fed by the module registry, a future app can contribute its own widget without the dashboard being rebuilt.
Account & role management
The portal owns identity, so this is where an admin creates users and assigns roles. Since it's built to be extensible, the role system should be general enough that a new app can declare its own permissions and have them slot in — rather than roles being hard-coded to the first two apps.
Single sign-on flow
Log in once at the portal, move between any installed app without logging in again.
Global search (optional, grows with the platform)
A search entry point that can query across installed apps. Worth noting it becomes more valuable as more apps are added, so it's a reasonable thing to defer until there's more than two apps to search.
5. Integration with Installed Apps
The portal sits above the apps rather than beside them:
- It authenticates the user and hands that identity/role to each app.
- It reads summary data from each app to build the dashboard, but doesn't modify their records — it links out to the relevant app for actual editing.
- It holds the shared user accounts every app relies on.
- It maintains the registry of which apps exist and who can see them — the mechanism that makes adding future apps straightforward.
6. Security
The portal is the most security-critical piece because it's the front door — compromise it and you're into every app beneath it:
- It holds the authentication system, so password hashing, session handling, and (worth considering) two-factor live here, using an established framework rather than anything hand-rolled.
- Role-based access control is defined centrally and enforced in each app — and the design should let a future app register its permissions without loosening the existing model.
- A login/access audit trail (who logged in, when, failed attempts) belongs at this layer.
- Since it's staff-only, access should be locked to TechToss accounts — no public sign-up path.
1. Purpose & Scope
The portal is the staff-only front door and connective tissue for TechToss's internal tools. It owns no domain data of its own — instead it provides the single login, the navigation, and the overview that individual apps can't give alone. Critically, it's built to grow: Inventory and Transactions are the first two apps to live under it, but the portal should treat "an app" as a general slot so future tools (reporting, refurbishment tracking, volunteer scheduling, whatever helps the workflow and tabulation) can be added with minimal friction.
This is also the shared authentication layer flagged in both prior outlines. Rather than each app inventing its own accounts, the portal handles login once and passes that identity to every app under it — designed a single time, reused by everything that plugs in.
2. Core Responsibilities
The portal is defined by function rather than a data model. Its main jobs:
3. Key Design Principle: Extensibility
Because the point is future growth, this deserves to be a first-class concern rather than an afterthought:
4. Key Features
App launcher / home
The landing page after login: the set of apps this staff member can access, presented as a simple, extensible list or grid. New apps appear here once registered.
Unified dashboard
The portal's main value beyond login — highlights from whatever apps are installed in one view. Today that's stock counts and items ready to move (Inventory) plus recent transactions and total dollars donated this period (Transactions). Because it's fed by the module registry, a future app can contribute its own widget without the dashboard being rebuilt.
Account & role management
The portal owns identity, so this is where an admin creates users and assigns roles. Since it's built to be extensible, the role system should be general enough that a new app can declare its own permissions and have them slot in — rather than roles being hard-coded to the first two apps.
Single sign-on flow
Log in once at the portal, move between any installed app without logging in again.
Global search (optional, grows with the platform)
A search entry point that can query across installed apps. Worth noting it becomes more valuable as more apps are added, so it's a reasonable thing to defer until there's more than two apps to search.
5. Integration with Installed Apps
The portal sits above the apps rather than beside them:
6. Security
The portal is the most security-critical piece because it's the front door — compromise it and you're into every app beneath it: