Skip to content

feat: designated area

Vandana reddy Balannagari requested to merge feat/designated-area into develop

Overview

Implements the frontend layer for the "Designated Area/Workstation Assignment" feature. This feature splits the generic volunteer dashboard into specialized area dashboards and provides administrators with the tools to manage volunteer assignments across various workstations.

What does this MR do and why?

  • Area-Based Dashboards: Volunteers are now dynamically routed to area-specific dashboards (e.g., RegistrationDashboardPage, MedicineDashboardPage) instead of seeing a single, cluttered dashboard. This focuses their tasks strictly on their assigned station.
  • Admin Workstation Management: Introduces the WorkstationAssignmentPage allowing admins to view real-time volunteer counts across different zones and seamlessly assign or reassign volunteers.
  • UX Fixes & Polishing: Fixed doctor reassignment dropdown options (blocking REPEAT_MEDICINE selection), added a quick-access + button in the MedicineDashboardPage to jump to Queues, and resolved UI translation discrepancies.

Changes Made

  • New Pages & Dashboards:
    • src/pages/admin/WorkstationAssignmentPage.tsx
    • src/pages/volunteer/RegistrationDashboardPage.tsx
    • src/pages/volunteer/MedicineDashboardPage.tsx
  • Core State & Logic:
    • src/pages/DashboardPage.tsx: Integrated logic to redirect volunteers based on their workstation assignment state.
    • src/services/areaService.ts: Added frontend API service layer pointing to backend endpoints for stats and area assignments.
    • src/config/campAreas.ts: Configuration module detailing all valid designated areas in the medical camp.
  • Minor UI Adjustments:
    • src/pages/volunteer/AssignDoctorPage.tsx: Filtered out invalid REPEAT_MEDICINE target.
    • src/App.tsx: Wired up routes for new dashboard pages.
  • Localization Updates:
    • Added string translations across en/translations.json, te/translations.json, and ta/translations.json for new UI components.
  • Testing Improvements:
    • Added WorkstationAssignmentPage.test.tsx, RegistrationDashboardPage.test.tsx, MedicineDashboardPage.test.tsx, and areaService.test.ts.
    • Updated existing DashboardPage.test.tsx, AttendanceMarker.test.tsx, and AssignDoctorPage.test.tsx ensuring 100% test pass rates and proper mocks.

Technical Details

  • Routing Refactor: Previously, all volunteers hit a generic action dashboard. Now, DashboardPage checks the active VolunteerCampFlow state or API data to determine the user's assigned area and act as a smart router/delegator.
  • Extensible Configuration: Extracted all area-related constants out into src/config/campAreas.ts so adding a new medical camp zone in the future doesn't require fishing through disparate components.
  • Strict Testing Coverage: Enforced robust mock testing involving context-based routing transitions that simulate volunteer area swapping.

Type of Change

  • 🐛 Bug fix (non-breaking change that fixes an issue)
  • ✨ New feature (non-breaking change that adds functionality)
  • 💥 Breaking change (fix or feature that would cause existing functionality to change)
  • 📝 Documentation update
  • 🎨 UI/UX improvement
  • ♻️ Refactor (no functional changes)
  • ⚡ Performance improvement
  • 🧪 Test update
  • 🔧 Configuration change
  • 🚨 Security fix

Related Issues / References

closes#347

Screenshots or Screen Recordings

designated_area

Before After
Volunteer Dashboard Configurable Route via Registration/Medicine Dashboard

How to Set Up and Validate Locally

  1. Pull this branch / checkout MR: feat/designated-area
  2. Run development server: 
    npm run dev
  3. Run tests ensuring robust coverage: 
    npm test
  4. Volunteer Path: Log in as a volunteer and observe how you are routed dynamically to a specialized dashboard corresponding to your current area assignment (e.g. Medicine Dashboard). Test out the new + navigation flow here.
  5. Admin Path: Log in as an Administrator and head to /admin/workstation-assignment. Reassign a test volunteer between areas. Log back deeply into the volunteer account to see their dashboard route change.

Testing Done

  • Manual testing completed
  • Unit tests added/updated

Test Cases Covered:

Scenario Expected Result Status
Volunteer Landing Navigation Renders the correct area dashboard based on flow state ✅
Admin View Volunteers Render volunteer count correctly per station ✅
Admin Reassign Volunteer Effectively swaps volunteer to new active zone ✅
Reassign Doctor Exclusion Specialization REPEAT_MEDICINE filtered across swap actions ✅
Medicine Dashboard Navbar The + buttons accurately pushes /volunteer/queues route ✅
CI Test Suite Integrity npm test successfully executes over 1,790 validations ✅

Code Quality Checklist

Code Standards

  • Code follows project conventions (naming, structure, formatting)
  • No console.log() or debugger statements left in code
  • No unused imports, variables, or functions
  • No duplicate code and use of existing components for reusability
  • i18n check passed with no hardcoded strings in codebase for i18n support
  • TypeScript types are properly defined (no any unless justified)
  • ESLint and Prettier checks pass

React Best Practices

  • Components are properly split and single-responsibility
  • Hooks follow rules (no conditional hooks, proper dependencies)
  • State management is appropriate (local vs global state)
  • No unnecessary re-renders (memoization used where needed)
  • Event handlers are properly cleaned up

Component Patterns

  • shadcn/ui components used correctly
  • Tailwind classes follow utility-first approach
  • Responsive design considered (mobile-first if applicable)
  • Accessibility attributes included (aria-*, role, etc.)
  • Icons from lucide-react used consistently

API & Data Fetching

  • Loading and error states handled within the area services
  • API types defined in src/types/api.ts
  • Axios interceptors handle auth tokens correctly

Error Handling

  • Errors are caught and handled gracefully
  • User-friendly error messages displayed
  • Errors are being toasted properly

Documentation

  • README.md updated (if setup steps changed)
  • .env.example updated (if new env vars added)
  • CHANGELOG.md updated (if applicable)

Known Limitations / Technical Debt

None

Additional Notes

The corresponding backend logic for area stats polling endpoint and assignments must exist concurrently on the actual environment. Ensure backend changes associated with "Designated Areas" are merged and live on development simultaneously for E2E consistency.

MR Acceptance Checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Vandana reddy Balannagari

Merge request reports