Feat: add food preferances in for the volunteers signup(opt for breakfast,opt for lunch(veg,non veg))
Merge Request: Food Preferences at Camp Signup + OTP in Response
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
-
