Tracker

Copy .env.example to .env and fill the credentials:

VITE_SUPABASE_URL="YOUR_SUPABASE_PROJECT_URL"
VITE_SUPABASE_ANON_KEY="YOUR_SUPABASE_ANON_KEY"

The Telegram bot token and chat id are Supabase Edge Function secrets, not Vite variables - set them with supabase secrets set TELEGRAM_BOT_TOKEN=... TELEGRAM_CHAT_ID=....

Requires Bun 1.3.1 (pinned via packageManager in package.json), a Supabase project, and a Telegram bot with its chat id.

The notifier lives in supabase/functions/send-telegram-notify. It is invoked when a pharmacist sends an order group from the order screen, not when a draft is first created. It requires a signed-in pharmacist or admin, loads the order rows itself, and builds the Telegram message server-side; the client only sends order ids. It records each supplier group in the telegram_notifications table so a retry after a timeout cannot send the same Telegram message twice. Apply supabase-schema.sql first, then deploy with the Supabase CLI (Docker is not required):

⟫ bunx supabase login
⟫ bunx supabase link --project-ref YOUR_PROJECT_REF
⟫ bunx supabase functions deploy send-telegram-notify

Secrets stay in the Supabase project (TELEGRAM_BOT_TOKEN, TELEGRAM_CHAT_ID); they are never Vite variables. Firebase Hosting, Vercel domains, and local development are allowed by default; for a custom domain, set ALLOWED_ORIGINS to a comma-separated list of browser origins. Local CLI state such as supabase/.temp/ is ignored by git.

Procurement data is invite-only. Access is controlled by public.profiles: a signed-in user with no profile row (or with role pending) can read nothing, and only an administrator can change the allowlist.

Deleting procurement records is admin-only; pharmacists can delete automatic plans because that is the only delete action in the app. The generate-auto-orders edge function also checks the caller's profile before a manual run, since it writes with the service role and bypasses RLS.

First deploy / existing project

Run these steps before deploying the app, because the login flow now checks the caller's profile.

1. Apply supabase-schema.sql. It creates profiles and replaces the blanket policies with role-scoped ones.
2. Bootstrap the first administrator in the SQL editor, replacing the email:

   insert into public.profiles (id, email, role)
   select id, email, 'admin'
   from auth.users
   where email = 'admin@hospital.go.th'
   on conflict (id) do update
     set email = excluded.email, role = 'admin', updated_at = now();

3. Add each staff member the same way with 'pharmacist' or 'viewer'. auth.users lists the accounts; a profile row is what grants access.
4. Turn off public sign-ups so new accounts cannot be created from the login endpoint. Either use Dashboard > Authentication > Settings and disable "Allow new users to sign up" (keep the Email provider enabled), or run bunx supabase config diff then bunx supabase config push to push [auth] enable_signup = false from supabase/config.toml.

Accounts without a staff role see a "waiting for approval" screen. Deleting the profile row (or the auth user) revokes access immediately.

The plan runner lives in supabase/functions/generate-auto-orders and creates draft orders in ต้องสั่งซื้อ, then notifies the pharmacy chat.

1. Apply the new tables in supabase-schema.sql (auto_order_plans, auto_order_runs).
2. Deploy the function: ⟫ bunx supabase functions deploy generate-auto-orders
3. Set the shared cron secret on the function and store the same value in Vault: ⟫ bunx supabase secrets set CRON_SECRET=....
4. Enable pg_cron + pg_net, then run supabase/cron/auto-order-plans.sql. The job runs daily at 08:00 Asia/Bangkok.

A plan stores the historical usage you enter (quantity over a number of months) and the reorder interval; the runner calculates the draft quantity from those values. The page also has a dry-run button, so a plan can be tested without writing orders or sending Telegram. Each plan uses the calculated quantity by default; tick "กำหนดเอง" in the plan form to store an explicit order_quantity per cycle (for example, to match a supplier's pack size). Run supabase-schema.sql before deploying so the column exists.

The reminder runner lives in supabase/functions/send-overdue-reminders. It sends one plain-text follow-up per supplier for orders that have been สั่งแล้ว longer than OVERDUE_DAYS (default 14). It only reads orders and sends Telegram; it never changes procurement state.

1. Set CRON_SECRET as a function secret and store the same value in Vault. Optional: set OVERDUE_DAYS and SIGNATURE.
2. Deploy the function: ⟫ bunx supabase functions deploy send-overdue-reminders
3. Enable pg_cron + pg_net, then run supabase/cron/overdue-reminders.sql. The job runs Monday-Friday at 08:00 Asia/Bangkok.