-- Owner-tunable automation timings (auto-checkout, auto-cancel, reminder lead).
-- Idempotent so re-runs in dev are safe. Defaults match the pre-existing
-- hard-coded behavior so existing workspaces don't change behavior on deploy.

ALTER TABLE "Owner" ADD COLUMN IF NOT EXISTS "autoCheckoutTime" TEXT NOT NULL DEFAULT '00:00';
ALTER TABLE "Owner" ADD COLUMN IF NOT EXISTS "autoCancelTime" TEXT NOT NULL DEFAULT '00:01';
ALTER TABLE "Owner" ADD COLUMN IF NOT EXISTS "reminderHoursBefore" INTEGER NOT NULL DEFAULT 24;
ALTER TABLE "Owner" ADD COLUMN IF NOT EXISTS "lastAutoCheckoutAt" TIMESTAMP(3);
ALTER TABLE "Owner" ADD COLUMN IF NOT EXISTS "lastAutoCancelAt" TIMESTAMP(3);

-- Seed last-run timestamps to NOW() for existing workspaces. The cron's
-- shouldRunToday() returns false when last-run-date == today's-date, so
-- this prevents both sweeps from firing on the day this feature deploys
-- — operators get a 24h grace period to confirm the new behavior before
-- any data moves. New workspaces created after deploy have NULL stamps
-- and will run on their first qualifying tick as designed.
UPDATE "Owner" SET "lastAutoCheckoutAt" = NOW() WHERE "lastAutoCheckoutAt" IS NULL;
UPDATE "Owner" SET "lastAutoCancelAt"   = NOW() WHERE "lastAutoCancelAt"   IS NULL;

-- Grandfather Walk-in permission. The createVisitor policy gate was
-- relaxed from `(canPolicyPre OR canPolicyWalkIn)` to `canPolicyWalkIn`
-- only, since pre-approval is removed and walk-in is its replacement.
-- Without this backfill, any sub-admin previously granted canPolicyPre
-- (but not canPolicyWalkIn) would be silently locked out of the
-- "Walk-in (here now)" card on the Add Visitor form. Idempotent — the
-- OR keeps existing canPolicyWalkIn=true rows untouched.
UPDATE "Admin"
SET "canPolicyWalkIn" = TRUE
WHERE "canPolicyPre" = TRUE
  AND "canPolicyWalkIn" = FALSE;
