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.
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:They aren't
Dateobjects — 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
applications_enabledsetting (seeded in000006_seed_settings.up.sql), toggled by a super admin inPermissionsTab.tsx, enforced byApplicationsEnabledMiddleware(cmd/api/middlewares.go:208) over the PATCH/submit/resume routes. Someone flips a switch; no date is stored.PATCH /v1/superadmin/applications/{id}/status.hackathon_date_rangesetting ({start_date, end_date}) is fully plumbed: store methods ininternal/store/settings.go:465-510, super-admin GET/POST at/superadmin/settings/hackathon-date-range, and a hacker-readable endpointGET /v1/schedule/date-range(cmd/api/api.go:179). Seedednull/null, currently only used to lay out schedule day columns, butstart_dateis 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
hackathon_date_rangepattern ininternal/store/settings.go).applications_enabledtoggle with a deadline the middleware compares against — keep the boolean as a manual override for closing early.Frontend
null, so "unconfigured" is already detectable —HackathonDateRangeResponseexposes aconfiguredflag for this).IMPORTANT_DATESinDashboardPage.tsxwith fetched values; wire Kickoff to the existingGET /v1/schedule/date-range.Open questions