Signal — Access Model

This page documents the complete access-control model of Signal, Power Digital's internal business-intelligence web app: the five-tier role ladder (Member → Team Lead → Admin → Gandalf → Sauron), the orthogonal Growth grant system, every frontend route guard, how each flag is granted, and a route-by-route table of effective audiences. Everything here is verified directly against the code at staging @ 98df0c4 (verified 2026-07-07), primarily src/App.tsx (routes, guards, sidebar) and src/context/AuthContext.tsx (flag resolution), with server-side enforcement in server/index.ts.

Signal sign-in is Google OAuth via Signal's auth service (Supabase). Only three email domains may sign in — a hardcoded allowlist (ALLOWED_DOMAINS in src/context/AuthContext.tsx): powerdigitalmarketinginc.com, external.powerdigitalmarketinginc.com, cardinaldigitalmarketing.com. Any other domain is signed out with "Access restricted to authorized Power Digital and Cardinal email domains only." Deep links survive login (the path is stored in sessionStorage and restored after the OAuth redirect). Local development can bypass auth entirely with VITE_DEV_BYPASS_AUTH=true, which sets every flag true.

On first sign-in the frontend calls POST /api/auth/ensure-provisioned, which creates the user's row in Signal's app_users role table with all flags false — except that anyone who is an Executive Sponsor (Account Director) or Group Director on any active client in Nova is auto-upgraded to Team Lead (is_team_lead = true). Provisioning never downgrades an existing Team Lead. All role flags are cached in the browser's sessionStorage (keys like signal_admin_v1_<email>) so a page refresh does not flash access away; the cache is reconciled against the database in the background, and an ambiguous/failed database read never revokes cached access mid-session.

Signal's role ladder is resolved in src/context/AuthContext.tsx from Signal's own app_users Supabase table plus two hardcoded code lists:

Growth flags are separate and NOT part of the ladder (next section). A further independent list, PAYROLL_AUTHORIZED_EMAILS in server/index.ts (a hardcoded list of exactly 15 emails as of Jul 2026), gates the payroll/personnel-expense API endpoints used by Divisional P&L — holding Gandalf is not sufficient for those endpoints.

Growth access controls Signal's most sensitive area — the Growth section: People (/growth/people, per-person salary/payroll/compensation) and Performance Radar (/growth/performance-radar). It is orthogonal to the five tiers and is resolved by the backend from two Supabase tables (Signal's own records):

The frontend fetches GET /api/growth/my-access at sign-in; the response sets four flags in AuthContext: isGrowthAllowed (has any division grant), canViewPeople, canViewRadar, and canManageGrowthAccess (OR'd with Sauron). All four are sessionStorage-cached like the tier flags.

On top of the grants sits a second factor: each Growth viewing tab is wrapped in GrowthTabGate (in src/App.tsx), which prompts for a shared unlock password. The password is validated against a real gated endpoint before being stored, sent as the x-growth-key header on every /api/growth request, and checked server-side against the GROWTH_UNLOCK_KEY environment variable — so a locked tab genuinely cannot load data; this is enforcement, not a hidden screen. The key is held in browser memory only (src/services/growthUnlock.ts): a page reload forces re-entry, and it re-locks after the app has been backgrounded ≥ ~5 minutes. The Growth Access management endpoints require the same key plus requireGrowthManage.

What changed recently (July 2026): before July 2026, Growth access was a hardcoded email allowlist in the code. Migration 20260701_growth_access_grants.sql replaced it with database-backed grants (seeding the 8 previously-allowlisted emails as all-division grants so nobody lost access on deploy); 20260702 added department-level scoping for the three large divisions; 20260703 added the per-tab capability system (can_view_people / can_view_radar / can_manage_access), which split the old single Growth gate into per-tab gating — Performance Radar is now hidden by default and granted per user. The new management screen at /growth/access (guard GrowthManageRoute) delegates administration to Growth managers without requiring Admin or Gandalf, and a new "Access" sidebar section now holds both "General Access" (/users, Gandalf) and "Growth Access" (/growth/access, Growth managers). Gandalf is deliberately NOT auto-granted Growth Access management.

All guards live in src/App.tsx and redirect failing users to /summary (except GrowthTabGate, which renders a password prompt in place):

Sidebar visibility mirrors the guards: nav links carry flags (teamLeadOnly, adminOnly, gandalfOnly, sauronOnly, peopleOnly, radarOnly, manageGrowthOnly) and are filtered per user; Members' sidebars are stripped to exactly Summary and Employees. Server-side, every sensitive API route re-checks access with middleware (requireAuth, requireAdmin, requireGandalf, requireGrowthAccess, requireGrowthManage, requirePayrollAccess) that re-reads the role/grant tables with 2–5 minute caches — hiding a nav item is never the only protection.

Every route mounted in src/App.tsx as of staging @ 98df0c4 (2026-07-07):

Two audience subtleties worth stating plainly: (1) a Growth-only user (holding a Growth grant or capability but no Team Lead flag) is not a Member, so MemberAllowedRoute routes — Staffing, ETCR, and all the Client Health prediction views — are technically reachable for them, even though the intended audience is Team Lead and above. (2) The Iris AI chat drawer (Cmd/Ctrl+I) is not route-gated: its enable check is the isAdmin flag specifically (IrisContext.tsx), so Admins and Saurons get it, Members never see the button, and a Gandalf-only user without is_admin does not get it despite passing AdminRoute gates elsewhere.

Changes to the access model shipped around June–July 2026, in case a user asks "why does access look different":