feat : Add the automatic camp creation on first sunday of the every month
Overview
This MR introduces automatic scheduling of medical camps. Once an admin creates a medical camp, the system will automatically schedule the next camp on the first Sunday of the following month at Swecha Office, Gachibowli.
This feature reduces manual effort and ensures a continuous schedule of camps without gaps.
What does this MR do and why?
Motivation
Currently, admins must manually create each medical camp every month, which is repetitive and error-prone.
Approach
- Implemented helper functions to calculate the first Sunday of a month
- Extended the service layer to automatically create the next camp
- Added database validation to prevent duplicate entries
Trade-offs
- Slight increase in logic complexity in the service layer
- Assumes fixed location (Swecha Office, Gachibowli) for automation
Changes Made
- Added logic for automatic next-month camp scheduling
- Introduced helper functions for date calculation
- Updated service layer (create_medical_camp)
- Added duplicate prevention checks in database queries
- Added logging for tracking automation events
Technical Details
Root Logic
- Compute next month
- Find first Sunday
- Check if a camp already exists for that date & location
- If not → create new camp
Architecture Decisions
- Logic placed in service layer to keep controllers clean
- Reused existing models and schemas (no schema changes)
Data Flow
- Admin creates camp
- Service calculates next month’s first Sunday
- DB check for duplicate
- Auto-create next camp
Type of Change
-
🐛 Bug fix -
✨ New feature -
💥 Breaking change -
📝 Documentation update -
♻ ️ Refactor -
⚡ Performance improvement -
🧪 Test update -
🔧 Configuration change -
🚨 Security fix -
🗑 ️ Deprecation
Related Issues / References
- Related to: Medical Camp Scheduling Automation
Screenshots or Screen Recordings
- API tested via Swagger (/docs)
- Verified automatic camp creation in database
- Logs confirm auto-trigger execution
How to Validate Locally
-
Start the backend server: uvicorn app.main:app --reload
-
Create a medical camp via API or Swagger
-
Verify:
- A new camp is automatically created for next month
- Date should be first Sunday
- No duplicate entry exists
Previous Behaviour
- Admin manually created every camp
New Behaviour
- System auto-generates next month's camp
Testing Done
-
Unit tests added/updated -
API endpoint tests passing
Test Cases Covered:
| Scenario | Expected Result | Status |
|---|---|---|
| Create first camp | Next month camp auto-created | |
| Duplicate check | No duplicate camp created | |
| Date validation | First Sunday correctly calculated |
Test Commands Run: pytest pytest --cov=app
Code Quality Checklist
Code Standards
-
Code follows project conventions -
No debug statements left -
No unused imports -
No duplicate code -
Proper type hints added -
Ruff checks pass
Python & FastAPI Best Practices
-
Single responsibility followed -
Async/await used correctly -
Dependency injection used -
Pydantic validation used -
Optimized queries -
Proper error handling
API Design
-
RESTful conventions followed -
Proper HTTP status codes -
Input validation implemented -
Authentication enforced -
RBAC used -
API docs updated
Database & Migrations
-
No schema changes required -
No migration needed -
ORM used (no raw SQL) -
Data integrity maintained
Security
-
No sensitive data logged -
SQL injection safe (ORM used) -
Input sanitization done -
Secure token handling -
Proper CORS config
Error Handling
-
Graceful error handling -
User-friendly messages -
Proper logging
Documentation
-
README.md updated -
.env.example updated -
API documentation updated -
CHANGELOG.md will be updated -
Comments added for complex logic
Known Limitations / Technical Debt
- Location is currently fixed (Swecha Office, Gachibowli)
- Future enhancement: allow configurable locations and schedules
Additional Notes
- Designed to be easily extendable for:
- Weekly camps
- Multiple locations
- Custom recurrence rules
MR Acceptance Checklist
Quality & Correctness
-
Code works as intended -
No bugs introduced -
Edge cases handled
Maintainability
-
Code is readable -
Code is testable -
Follows project patterns
Acceptance Review
-
Reviewed by at least 1 teammate -
Reviewed by product owner
Edited by Banuri Koushik Reddy