Supplier Account Inventory

An internal tool for submitting, reviewing, assigning, and controlling access to supplier account credentials ("IDs"). There are three kinds of user, each with their own sign-in and their own screens:

Role	How the login is created	What they can do
Supplier	Signs up himself at /signup	Submit IDs; see his own dashboard — how many IDs he gave, and which were accepted or rejected (with the reason), day by day, and which IDs he has been paid for (with the date — never the amount). Only accepted IDs are paid. Never sees a stored password again, and never sees another supplier's IDs.
Media buyer	Added by an admin on Suppliers & buyers	See only the IDs assigned to him, with their login details (passwords, Outlook mail, temp mail, 2FA key) shown in plain text so he can check them, change a password / 2FA key if it changes, and mark each one active or rejected (a note saying why is required). The New today count and filter show which IDs he was given today.
Admin	Promoted by hand (see below)	See everything, credentials shown in plain text; change any ID's passwords / 2FA key; accept or reject IDs; assign IDs to a media buyer by name, one at a time or in bulk; add media buyers; see on which date each supplier gave how many IDs, pay for that day's accepted IDs (Mark paid with the amount), and see each month's IDs bought / pending / accepted / rejected / paid for and the total spent (dashboard and Supplier payments); export.

Life of an ID: a supplier submits it (pending) → an admin accepts it, or assigns it to a media buyer, which also accepts it (accepted) → the media buyer checks it and marks it active or rejected. An admin can also reject, archive or reassign at any point. Credentials are shown in plain text on an ID's page, to an admin or the media buyer it is assigned to only; every time that page is opened it is freshly authorized and audit-logged.

Stack: Next.js 16 (App Router) + TypeScript + Tailwind CSS v4, Supabase (Postgres + Auth). Credentials are stored as plain text — no encryption key is needed (see Credential storage).

Table of contents

• Quick start (demo mode)
• Setting up a real Supabase project
• Credential storage (plain text)
• Creating the first admin
• Role management
• Deployment
• Security model summary
• Data retention
• What works today vs. what needs configuration

Quick start (demo mode)

With no configuration at all, the app runs in demo mode: an in-memory, fictional data set with a demo admin, two demo media buyers and two demo suppliers. Nothing is persisted — it resets every time the server restarts — and this is loudly banner-labeled in the UI. The view/audit flow behaves like production, just without durability.

npm install
npm run dev

On Windows you can instead double-click start-app.bat, which runs those two commands and opens the browser.

Open http://localhost:3000 — you'll land on the sign-in page. In demo mode, pick any of the listed demo users to see that role's screens (a simulated sign-in, clearly marked as such — see src/app/actions/auth.ts), or use Create an account to try the supplier sign-up.

Setting up a real Supabase project

1. Create a project at supabase.com.
2. In the SQL editor, run the migrations in supabase/migrations/ in filename order:
   • 0001_schema.sql — tables, triggers, the profiles role sync trigger.
   • 0002_rls.sql — Row Level Security policies. This is the real authorization boundary; the app's server checks are a second layer, not a substitute.
   • 0003_secret_presence.sql — a narrow, presence-only RPC so the UI can show "a value is stored" without ever exposing ciphertext through it.
   • 0004_two_factor_secret.sql — allows storing an encrypted 2FA key.
   • 0005_roles_assignment.sql — supplier / media buyer / admin roles, which supplier an ID belongs to, which media buyer it is assigned to, the accepted / rejected statuses and the rejection note. If your database already exists, this is the one you still need to run. It is safe to run more than once; it renames the old team role to supplier and moves any needs_review IDs back to pending.
   • 0006_buyer_source.sql — lets a media buyer add IDs of his own.
   • 0007_supplier_payments.sql — the Supplier payments page: which supplier was paid for which day. Admin-only (RLS). Safe to run more than once.
   • 0008_paid_per_id.sql — only accepted IDs are paid; each paid ID gets its own paid_at. Run it before deploying the version that uses it. Safe to run more than once.
3. Optionally run supabase/seed.sql for fictional sample suppliers/accounts (no secrets — attach fictional secret values afterward through the app UI).
4. Copy .env.example to .env.local and fill in:
   • NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY — Project Settings → API.
   • SUPABASE_SERVICE_ROLE_KEY — same page. Server-only. Never expose this to the browser, never prefix with NEXT_PUBLIC_, never commit it.
   • ENCRYPTION_KEYS — optional, only to read credentials saved before they were stored as plain text; see the next section.
5. npm run dev. The app detects the Supabase env vars and leaves demo mode automatically.

This is the beginning of the README. Read the rest at the original. Read the full README ↗