Fix volunteer signup page state for active vs past latest camp
Overview
This MR fixes inconsistencies in the volunteer join/signup flow where users were shown incorrect UI states (such as signup for past camps or missing camp data). It ensures the frontend strictly follows the backend’s latest-camp logic and displays the correct state.
What does this MR do and why?
The volunteer join page previously relied on incomplete or loosely validated backend data, which caused:
- Signup CTA to appear even when no valid camp existed
- Past camps being treated as active
- Missing camp data still showing signup UI
This MR introduces strict validation for camp availability using:
camp_idcamp_date
and ensures that only today/future camps are considered valid.
This aligns the frontend behavior with backend logic and eliminates misleading UI states.
Changes Made
-
Updated volunteer join page logic to validate:
- presence of
camp_id - presence of
camp_date
- presence of
-
Introduced a dedicated "No camp scheduled" UI state when:
- camp is missing
- camp date is missing
- camp date is in the past
-
Ensured signup UI is shown only when:
- camp is valid
- camp is today or in the future
- volunteer is not already signed up
-
Preserved:
- signed-up state handling
- dashboard navigation
- QR attendance flow
-
Updated frontend tests to cover edge cases:
- past camp
- missing camp data
- already signed-up user
Technical Details
Root Cause:
- Frontend did not strictly validate camp availability
- Relied on partial backend response
- Defaulted to signup CTA when state was unclear
Fix:
-
Introduced strict checks:
camp_id && camp_datecamp_date >= today
-
Added explicit fallback UI instead of generic signup
Type of Change
-
🐛 Bug fix (non-breaking change that fixes an issue) -
✨ New feature -
💥 Breaking change -
📝 Documentation update -
🎨 UI/UX improvement -
♻ ️ Refactor -
⚡ Performance improvement -
🧪 Test update -
🔧 Configuration change -
🚨 Security fix
Related Issues / References
- Fixes volunteer signup flow inconsistency issue
- Aligns with backend MR for latest-camp logic
Screenshots or Screen Recordings
| Before | After |
|---|---|
| Signup shown for past/missing camp | "No camp scheduled" shown |
| Incorrect CTA fallback | Correct conditional UI rendering |
How to Set Up and Validate Locally
-
Pull this branch:
git checkout <branch-name> -
Install dependencies:
bun install -
Run development server:
bun dev -
Test scenarios:
-
Case 1: No camp exists → Navigate to
/join-volunteer→ Expect: "No camp scheduled" -
Case 2: Camp date is in the past → Expect: "No camp scheduled"
-
Case 3: Valid future camp + not signed up → Expect: Signup UI visible
-
Case 4: Valid future camp + signed up → Expect: Redirect/dashboard/QR flow
Testing Done
-
Manual testing completed -
Unit tests updated
Test Cases Covered:
| Scenario | Expected Result | Status |
|---|---|---|
| Past camp | No camp scheduled | |
| Missing camp_id | No camp scheduled | |
| Missing camp_date | No camp scheduled | |
| Future camp (not signed up) | Signup UI shown | |
| Future camp (signed up) | Dashboard/QR flow |
Code Quality Checklist
Code Standards
-
Code follows project conventions -
No console logs/debuggers -
No unused code -
Reusable components used properly -
No hardcoded strings (i18n safe) -
Proper TypeScript types used -
ESLint & Prettier pass
React Best Practices
-
Proper component separation -
Hooks used correctly -
State management appropriate -
No unnecessary re-renders -
Cleanup handled
Component Patterns
-
shadcn/ui usage correct -
Tailwind used properly -
Responsive design considered -
Accessibility included -
Icons consistent
API & Data Fetching
-
API state handled correctly -
Loading/error states handled -
Proper typing used -
Validation handled
Error Handling
-
Errors handled gracefully -
User-friendly messages shown -
Toast/error UI handled
Documentation
-
README.md updated (not required) -
.env changes (none) -
CHANGELOG.md (optional)
Known Limitations / Technical Debt
- Relies on backend providing correct
camp_idandcamp_date - Further improvements could include stronger type validation at API layer
Additional Notes
- This MR strictly aligns frontend behavior with backend logic
- No changes made to attendance flow or dashboard logic
- Safe, isolated UI fix with minimal risk
MR Acceptance Checklist
This MR meets acceptance criteria for:
- Correct UI state handling
- Backend alignment
- Test coverage
- Low regression risk