Skip to content

feat: super admin onboarding to set application, decisions, and kickoff dates #90

Description

@balebbae

Problem

The Important dates section on the hacker dashboard is fake. All three cards are hardcoded strings in a const array at client/web/src/pages/hacker/dashboard/DashboardPage.tsx:27-31:

const IMPORTANT_DATES: ImportantDate[] = [
  { month: "Mar", day: "14", label: "App due" },
  { month: "Mar", day: "20", label: "Decisions" },
  { month: "Apr", day: "04", label: "Kickoff" },
];

They aren't Date objects — just month/day strings with no year, rendered straight into the cards. Nothing fetches them and nothing validates them, so they display identically forever. The "See all" link beside the heading goes to /app/schedule, which does render real DB-backed events, which makes the section look wired when it isn't. (Tell that these came from a design mockup: the card above says HackUTD 2026 while the dates say March/April — HackUTD runs in the fall.)

Current state of each date

  • App due — no deadline date exists anywhere. Closing applications is a boolean, not a date: the applications_enabled setting (seeded in 000006_seed_settings.up.sql), toggled by a super admin in PermissionsTab.tsx, enforced by ApplicationsEnabledMiddleware (cmd/api/middlewares.go:208) over the PATCH/submit/resume routes. Someone flips a switch; no date is stored.
  • Decisions — nothing at all. No setting, no column, no migration. Statuses change when a super admin calls PATCH /v1/superadmin/applications/{id}/status.
  • Kickoff — the only one with a real source. The hackathon_date_range setting ({start_date, end_date}) is fully plumbed: store methods in internal/store/settings.go:465-510, super-admin GET/POST at /superadmin/settings/hackathon-date-range, and a hacker-readable endpoint GET /v1/schedule/date-range (cmd/api/api.go:179). Seeded null/null, currently only used to lay out schedule day columns, but start_date is genuinely kickoff.

Proposed work

Add a super admin onboarding flow that prompts for the three dates up front, so the dashboard reflects reality instead of placeholders.

Backend

  • New settings keys + migrations for the application deadline and the decisions-release date (follow the hackathon_date_range pattern in internal/store/settings.go).
  • Super-admin GET/POST endpoints for each, plus a hacker-readable endpoint so the dashboard can fetch all three.
  • Consider replacing the manual applications_enabled toggle with a deadline the middleware compares against — keep the boolean as a manual override for closing early.

Frontend

  • Onboarding prompt for super admins when the dates are unset (all seed to null, so "unconfigured" is already detectable — HackathonDateRangeResponse exposes a configured flag for this).
  • Replace IMPORTANT_DATES in DashboardPage.tsx with fetched values; wire Kickoff to the existing GET /v1/schedule/date-range.
  • Decide the empty state: what the dashboard shows before a super admin has set the dates.

Open questions

  • Should the onboarding be blocking (a gate on first super-admin login) or a dismissible prompt?
  • Does the deadline need a time and timezone, or is a date enough? The middleware needs a precise cutoff if it's going to enforce it.

Metadata

Metadata

Assignees

Labels

backendGo API and database workenhancementNew feature or requestfrontendReact/TypeScript client work

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions