Ad screens — Next.js app

Core pages:

• /admin — sign in, upload ad videos, assign each one to an auto, watch the fleet on a live map with each tablet's status, address, and what's currently playing
• /player — what runs on each tablet. Registers itself with an auto number, downloads its ads once, and plays them fully offline from then on.

The authenticated admin area also includes driver management:

• /admin/drivers — search registered drivers, see who's due for their monthly payment, and register a new one from a modal right here (no separate page)
• /admin/drivers/[id] — a driver's profile: their linked tablet's live status, documents, and payment cycle with a "mark as paid" action
• /admin/drivers/[id]/edit — update a driver's details or replace individual documents
• /admin/history — ads that aren't live right now (paused, not started yet, or finished), kept off the main dashboard so it stays focused on what's actually running
• /admin/autos — every tablet in the fleet in one place: add a new one, set or edit its SIM number, see its live status/battery/last seen, turn its screen off or back on, or delete it
• /admin/reports — pick an auto and a date to see its GPS route for that day, drawn on a map

Plus a small Android app in android/ — a kiosk wrapper around /player (no watermark, screen always on, auto-launches after reboot). See android/README.md for install instructions and where to download the built APK.

---

1. Supabase

1. Create a project at supabase.com. Free tier is fine.
2. Existing installations only: before rerunning the current setup.sql, grant the trusted admin role to every approved pre-existing admin or Team access account. Replace the example email with one account's exact email, run this block in SQL Editor, then repeat the same exact-email block separately for each other approved pre-existing account. The block aborts unless each run updates exactly one account; never remove the email filter, broaden it, or automatically promote every user.

   do $$
   declare
     promoted_count integer;
   begin
     update auth.users
     set raw_app_meta_data = coalesce(raw_app_meta_data, '{}'::jsonb)
       || jsonb_build_object('role', 'admin')
     where lower(email) = lower('[email protected]');
   
     get diagnostics promoted_count = row_count;
     if promoted_count <> 1 then
       raise exception 'Expected exactly one admin account, updated %', promoted_count;
     end if;
   end $$;
   

3. SQL Editor → paste all of setup.sql → Run. Creates the autos, ads, and drivers tables, the ads and private driver-documents storage buckets, the security rules, and seeds one test auto (AUTO-01).
4. Authentication → Users → Add user. On a new installation, create the first login, then run the single-account SQL block from step 2 for that exact email. The admin sign-in screen asks for a mobile number + PIN, not an email — but Supabase Auth only stores email + password, so create the login like this:
   • Email → your mobile number followed by @smato.local, digits only. 9876543210 → [email protected].
   • Password → your PIN. Supabase requires at least 6 characters by default, so use a 6-digit PIN.
   • Tick "Auto Confirm User". This is the step people miss — without it Supabase waits for a confirmation email, which a fake @smato.local address can never receive, so sign-in fails forever with "Invalid login credentials". If you already created a user without ticking it, fix it by running this once in the SQL Editor (swap in the real email):

     update auth.users set email_confirmed_at = now() where email = '[email protected]';
     

   • Sign out and sign back in after adding the role so the session receives a fresh JWT. You only need to do this dashboard dance once. After that first login works, add everyone else from inside /admin itself — section, mobile + PIN, no Supabase dashboard needed (see step 6 for the extra key that section needs). Accounts created there receive the admin role automatically.

2. Run it locally

npm install
cp .env.local.example .env.local

Open .env.local and paste in your three values:

NEXT_PUBLIC_SUPABASE_URL=https://xxxxx.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJhb...
SUPABASE_SERVICE_ROLE_KEY=eyJhb...

Then:

npm run dev

Open http://localhost:3000 — you should see the two links.

The anon key is safe in the browser. The rules in setup.sql mean it can only read ads, check a device in, and post a GPS fix. Only a permanent signed-in account whose trusted app_metadata.role is admin can open the admin shell or manage protected data and storage. The service role key is different — it bypasses all of that, so it only ever lives in this env var, read server-side by app/api/admin/create-admin, never sent to the browser.

3. Deploy to Vercel

npm i -g vercel
vercel

Or push to GitHub and import the repo at vercel.com.

Then add the environment variables in Vercel: Project → Settings → Environment Variables. Add NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY, and SUPABASE_SERVICE_ROLE_KEY, then redeploy. Without them the app builds but can't reach your data (and Team access won't be able to add new logins).

You'll get a URL like https://your-app.vercel.app.

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