Skip to content

feat:Added food preferences in the signup for medical camp endpoint

Bikkumalla Sai Krishna requested to merge food_preferences_in_volunteer_signup into develop

Merge Request

Overview

This MR introduces support for capturing food preferences (breakfast, lunch, and dietary choice) during volunteer signup for a medical camp. It enhances the signup process by allowing optional inputs that help in better planning and logistics for camp organizers.

What does this MR do and why?

This change was motivated by the need to collect food-related preferences from volunteers during camp signup to improve operational planning (e.g., meal preparation and dietary accommodations).

The approach taken:

  • Extended the signup request schema to include optional food-related fields.
  • Updated the service layer to process and store these preferences.
  • Ensured backward compatibility by keeping the fields optional.
  • Updated test cases to validate both scenarios (with and without preferences).

Changes Made

  • Modified CampSignup schema to include:

    • breakfast
    • lunch
    • food_preference

  • Updated signup_user_for_camp service:

    • Added optional signup_data parameter
    • Processed food preferences and converted them into boolean values
    • Stored preferences in CampVisit model
    • Included preferences in API response

  • Updated API tests:

    • Added test case for signup with food preferences
    • Updated existing test to support optional input

  • Added service-level test:

    • Verified correct handling and storage of food preferences
    • Ensured response consistency

Technical Details

  • Introduced optional request fields using Pydantic with validation patterns:

    • "Yes" / "No" for breakfast and lunch
    • "Veg" / "Non-Veg" for food preference

  • Service Layer Flow:

    1. Accept optional signup_data
    2. Convert:
      • "Yes" → True
      • "No" → False
    3. Store values in CampVisit
    4. Return normalized response (Yes/No strings)

  • No database schema migration included (assumes fields already exist in model)

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
  • ♻️ Refactor (no functional changes)
  • ⚡ Performance improvement
  • 🧪 Test update
  • 🔧 Configuration change
  • 🚨 Security fix
  • 🗑️ Deprecation (removing deprecated code)

Related Issues / References

Screenshots or Screen Recordings

image

How to Validate Locally

  1. Run the application
  2. Call signup API without preferences:
    • Expected: Successful signup with default/null values
  3. Call signup API with preferences: 
    {
  "breakfast": "Yes",
  "lunch": "No",
  "food_preference": "Veg"
}

4.Verify:Response includes correct values.Data stored correctly in DB

Testing Done

  • Unit tests added/updated
  • API endpoint tests passing

Test Cases Covered:

Test Cases Covered

Scenario Expected Result Status
Signup without preferences Success with default values ✅
Signup with preferences Preferences stored correctly ✅
Service logic validation Boolean conversion works ✅

Test Commands Run:

pytest pytest tests/test_api/test_medical_camp_routes.py -v pytest tests/test_services/test_medical_camp_service.py -v pytest --cov=apppytest

Code Quality Checklist

Code Standards

  • Code follows project conventions (naming, structure, formatting)
  • No debug statements or commented-out code left (unless necessary and intended)
  • No unused imports, variables, or functions
  • No duplicate code (DRY principle followed)
  • Type hints are properly defined (no Any unless justified and no mypy type check errors)
  • Ruff checks pass: 
    ruff check .
ruff format . --check

Python & FastAPI Best Practices

  • Functions follow single-responsibility principle
  • Async/await used correctly (no blocking calls in async functions)
  • Dependency injection used appropriately
  • Pydantic models used for request/response validation
  • SQLAlchemy queries are optimized (no N+1 queries)
  • Error handling is comprehensive (try/except with proper logging)

API Design

  • RESTful conventions followed
  • Proper HTTP status codes returned
  • Input validation implemented
  • Authentication/authorization enforced
  • Role Base access control used for user restriction
  • API documentation (docstrings) updated

Database & Migrations

  • Database migrations created (if schema changed)
  • Database migrations version is pointing to the latest version (and version name follows project conventions)
  • Migrations are reversible (migrations contain downgrade scripts)
  • Indexes added for frequently queried fields
  • No raw SQL queries (using SQLAlchemy ORM)
  • Data integrity constraints maintained

Security

  • No sensitive data logged (passwords, tokens, PII)
  • SQL injection prevention verified (ORM used)
  • Input sanitization implemented
  • Authentication tokens handled securely
  • CORS settings appropriate
  • Security scan passes: 
    bandit -r app/

Error Handling

  • Errors are caught and handled gracefully
  • User-friendly error messages returned
  • Errors are logged appropriately
  • HTTP error responses follow API standards

Documentation

  • README.md updated (if setup steps changed)
  • .env.example updated (if new env vars added)
  • API documentation updated (docstrings, OpenAPI specs)
  • CHANGELOG.md will be updated (if applicable)
  • Code comments explain complex logic (not what, but why)

MR Acceptance Checklist

Quality & Correctness

  • Code works as intended and solves the stated problem
  • No bugs introduced (existing functionality not broken)
  • Edge cases handled appropriately

Maintainability

  • Code is readable and well-organized
  • Code is testable and well-tested
  • Follows project patterns and conventions

Acceptance Review

  • Reviewed by at least 1 teammate
  • Reviewed by product owner
Edited by Bikkumalla Sai Krishna

Merge request reports