Hardcoded Dummy Administrators in Hackathon Preview

[Benjtalkshow]

Hardcoded Dummy Administrators in Hackathon Preview

Description

When previewing a hackathon in the "Review" tab before publishing, the Administrators section displays hardcoded mock names instead of the actual hackathon creator or any invited administrators. This is a visual bug that surfaces fabricated data to real users during a critical step in the hackathon creation flow.

Dummy Data Currently Displayed:

• Brooklyn Simmons (OWNER)
• Annette Black (ADMIN)
• Cody Fisher (ADMIN)
• Ronald Richards (ADMIN)

Impact: Low/Medium — while purely visual, this creates genuine confusion for users who see unfamiliar names listed as administrators of their own hackathon, undermining trust in the preview and the creation flow overall.

---

Step-by-Step Reproduction

1. Navigate to "Host Hackathon" to start the creation wizard (/organizations/[id]/hackathons/new)
2. Fill in the required details up to the "Review" tab
3. Open the "Judging" or "Review" section
4. Observed: The "Administrators" list shows "Brooklyn Simmons" and the other mock names listed above
5. Expected: The list should show only the hackathon creator (the current authenticated user) as Owner, and any actual administrators added during the creation process

---

Root Cause Analysis

The mock data is hardcoded directly in the UI component as a static fallback, and the actual administrator data is never retrieved or passed down from parent components.

Hardcoded Mock Array

In components/organization/hackathons/new/tabs/components/review/JudgingSection.tsx, a defaultAdministrators array (lines 22–47) contains the dummy names. This array was likely used as placeholder scaffolding during development and was never replaced with real data.

Missing Data Flow

The JudgingSection component (line 51) defaults to the defaultAdministrators mock array when the administrators prop is undefined. The problem is that neither SectionRenderer.tsx nor ReviewTab.tsx currently retrieve or pass actual administrator or creator data to this component — so the prop is always undefined in production, and the mock data always renders.

---

Technical Details

Files to Modify

1. components/organization/hackathons/new/tabs/components/review/JudgingSection.tsx

• Action: Remove the defaultAdministrators mock array entirely (lines 22–47)
• Update the component to gracefully handle an empty, undefined, or loading state for administrators — render an appropriate empty state or skeleton rather than falling back to mock data
• The component must never render fabricated names under any circumstance, including during loading

2. components/organization/hackathons/new/tabs/review/ReviewTab.tsx

• Action: Retrieve the current authenticated user session (e.g., via authClient.getSession()) and construct a minimal administrator entry representing the creator as "OWNER"
• Pass the user's name, email, and/or avatar as the initial administrator to the downstream renderer
• Handle the case where session data is still resolving — defer rendering the administrators list or show a loading skeleton until the session is available, rather than rendering with empty or null values

3. components/organization/hackathons/new/tabs/components/review/SectionRenderer.tsx

• Action: Accept an administrators prop and pass it down to JudgingSection
• Ensure the prop is correctly typed — strictly no any types

Relevant Components

• JudgingSection.tsx — renders the administrators list in the review preview
• ReviewTab.tsx — parent responsible for retrieving session data and composing the preview
• SectionRenderer.tsx — intermediary that must thread the administrators prop through to JudgingSection

---

Proposed Resolution Plan

1. Delete the mock data — remove the defaultAdministrators array from JudgingSection.tsx entirely

2. Pass real session data — update ReviewTab.tsx to retrieve the current user and pass them as the "OWNER" administrator entry, using authClient.getSession() or the equivalent session hook already used elsewhere in the wizard

3. Thread the prop — update SectionRenderer.tsx to accept and forward the administrators prop to JudgingSection

4. Handle loading gracefully — ensure JudgingSection does not crash or render mock data while session data is still resolving; use a skeleton or deferred render pattern consistent with the rest of the creation wizard

---

⚠️ Caution

This is a production environment — not a sandbox.

• Code must be performant, accessible, and clean
• No dummy data — the defaultAdministrators array must be fully removed; no static fallback names should exist anywhere in the component tree
• AI-generated code will be scrutinized; poorly structured or "hallucinated" code will result in immediate issue closure
• Follow the existing design system: shadcn/ui, Tailwind, Framer Motion
• Strictly no any types in prop definitions or the administrator data shape

---

Testing & Verification

Automated Tests

npm run lint    # Ensure code quality
npm run build   # Verify no breaking changes in routing or types

Manual Verification

• Navigate through the hackathon creation wizard to the "Review" tab — confirm none of the mock names (Brooklyn Simmons, Annette Black, Cody Fisher, Ronald Richards) appear anywhere in the preview
• Confirm the current authenticated user is shown as "OWNER" in the Administrators section of the review preview
• Verify the component does not crash or render empty while the session is still loading — confirm a skeleton or deferred render is shown instead
• Confirm the defaultAdministrators array is fully removed from JudgingSection.tsx — no static fallback data remains in the file
• Verify SectionRenderer.tsx correctly accepts and forwards the administrators prop to JudgingSection without any any types in the prop definition
• Test with a slow or delayed session response — confirm the administrators list does not flash mock data before resolving to the real user
• Verify there is no regression in the rest of the Review tab — all other sections should render correctly after the prop threading changes to SectionRenderer.tsx
• Provide video evidence

[linear]

BOU-122

[coderabbitai]

🔗 Related PRs

#372 - Fix hackathon [merged]
#376 - Fix hackathon [merged]
#380 - Feat/minor ux fixes [merged]
#381 - Hackathon analytics [merged]
#382 - Judging dashboard [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[Emmzyemms]

Hello Maintainers,
I’m a full-stack and smart contract developer with experience building responsive frontend interfaces, scalable backend systems, and secure blockchain applications. I’m interested in contributing to this issue and believe I can deliver a clean, well-tested solution that aligns with the project’s standards.
I’m eager to learn, improve, and collaborate with the community while contributing meaningful value. I would appreciate the opportunity to work on this task.

[Cedarich]

I’d like to fix this issue.

The problem is clear — the Administrators section is rendering hardcoded mock data because real session data is never passed down. I’ll fully remove the defaultAdministrators array from JudgingSection.tsx and ensure the component never falls back to fabricated names under any condition.

In ReviewTab.tsx, I’ll retrieve the authenticated user session and construct a proper administrator entry for the creator as OWNER, then pass it down through SectionRenderer.tsx with strictly typed props (no any). I’ll also handle loading states gracefully so the UI shows a skeleton or deferred render instead of flashing empty or mock data.

I’ll verify the mock names are completely removed, ensure correct data flow, confirm no regressions in the Review tab, and provide video proof. Code will follow the existing design system and pass lint/build checks.

[Christopherdominic]

Hi 👋

I’d like to work on this issue.

I’ve reviewed the description and acceptance criteria, and I’m confident I can implement the required changes following the project’s guidelines and coding standards. I’ll ensure proper testing and documentation where applicable.

Please assign this issue to me — I’ll get started right away. 🚀

Thank you!

[gelluisaac]

I’m interested in tackling this! I have a strong background in smart contract development and full-stack systems, so I'm well-equipped to handle the requirements here. Could you please assign this to me?

[estyemma]

I'd like to work on this! I'm a full-stack/smart contract developer experienced in building scalable, secure Web3 interfaces. I’m ready to contribute a high-quality solution that fits the project’s standards.

[Oluwaseyi89]

Hi Maintainer! I’d like to resolve the hardcoded administrator issue by removing the defaultAdministrators fallback and properly wiring real creator and invited admin data through SectionRenderer and ReviewTab into JudgingSection. I will ensure the preview accurately reflects the authenticated user as Owner and any explicitly added administrators, restoring trust in the hackathon creation flow and eliminating fabricated UI data. Please, assign this issue to me.

[ryzen-xp]

Hi maintainers 👋
I’m a blockchain developer with strong expertise in Stellar, Rust,TS and Stellar SDK integrations. I’ve worked on multiple Stellar-based smart contract and backend systems.

I understand the scope of this issue and can deliver a reliable, production-quality solution with proper tests and documentation.
Plz assign me !!

ETA: 14 hours