Skip to content

Draft: Resolve "Feat: add food preferances in for the volunteers signup(opt for breakfast,opt for lunch(veg,non veg))"

Closes #50 (closed)

Summary

This MR extends the camp signup endpoint to optionally capture food preference information (food type, breakfast, and lunch) and stores it as part of the user's camp visit record. It also exposes the generated OTP in the send-OTP response body for development and testing purposes.

1. Food Preferences at Camp Signup

Endpoint: POST /api/v1/medical-camps/camp/signup

What was added

Users can now optionally provide food preferences when signing up for a medical camp. These preferences are stored on the camp_visits record for that user and can be used by camp organizers for meal planning.

New optional request body:

Files Changed

app/models/camp_visit.py

  • Added FoodTypeEnum with values veg and non_veg
  • Added three new nullable columns to the CampVisit model:
    • food_type — stores veg or non-veg preference
    • breakfast — boolean flag for breakfast
    • lunch — boolean flag for lunch

app/schemas/medical_camp.py

  • Added CampSignupRequest Pydantic schema with all three fields as optional (None by default)
  • food_type is validated via Literal["veg", "non_veg"] to reject invalid values

app/services/medical_camp_service.py

  • Extended signup_user_for_camp(db, user) to accept an optional food_preferences parameter
  • When provided, food preference values are resolved and stored on the CampVisit record at creation time
  • All existing signup logic (role hierarchy, duplicate check, etc.) is unchanged

app/api/v1/routes/medical_camp_routes.py

  • Added CampSignupRequest as an optional JSON request body to the signup endpoint using FastAPI's Body(default_factory=CampSignupRequest)
  • Food preferences are forwarded to the service layer
  • Swagger/OpenAPI documentation now shows all three new fields

alembic/versions/dfa6c146860a_add_food_preferences_to_camp_visits.py (new file)

  • Migration adds food_type (enum), breakfast (boolean), and lunch (boolean) as nullable columns to the camp_visits table
  • Downgrade removes the three columns cleanly

Constraints Maintained

  • No changes to authentication or authorization logic
  • No changes to the role hierarchy determination
  • No changes to the response format of the signup endpoint
  • No impact on any other endpoints or workflows (patient registration, queue management, consultations, prescriptions, analytics)

2. OTP Displayed in Send-OTP Response

Endpoint: POST /api/v1/auth/send-otp

File changed: 

app/api/v1/routes/auth_routes.py

What was changed

The generated OTP is now included in the response body in addition to the existing message field.

Why

SMS delivery is not functional in the development environment. Without the OTP being visible anywhere, the sign-up and forgot-password flows were untestable. Returning the OTP in the response allows developers to complete the full registration and password-reset flows during local development and testing.

Note: This change is intended for development/testing environments only. In production, SMS delivery should be functional and the OTP should never be returned in the API response.

Testing

  • tests/test_api/test_medical_camp_routes.py:
    • Signup with food preferences — verifies they are forwarded to the service
    • Signup without food preferences — verifies backward compatibility
  • tests/test_services/test_medical_camp_service.py:
    • Food preferences are persisted to the camp_visits record in the DB
    • All food columns remain NULL when no preferences are provided
Edited by Madavarapu Sai Harshavardhan

Merge request reports

Loading