Draft: refactor(ehrs): simplify certificate download logic and remove eligibility endpoint

Merge Request

Overview

Refactored the certificate download feature by removing the redundant eligibility endpoint and consolidating the logic into a single backend endpoint. The system now enforces certificate access based on the volunteer's camp participation directly within the download API.

What does this MR do and why?

Changes Made

• Removed /certificate/eligibility endpoint along with its schema and test cases
• Updated GET /api/v1/users/{user_id}/certificate to:
  • Check volunteer eligibility internally
  • Return 403 Forbidden if the volunteer has attended fewer than 2 camps
• Ensured eligibility is determined based on attended/verified camp participation only
• Cleaned up related lint issues
• Updated test suite to reflect the new flow (all tests passing)
• Updated walkthrough.md with the latest implementation details

Technical Details

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

How to Validate Locally

Testing Done

• Unit tests added/updated
• API endpoint tests passing

Test Cases Covered:

Scenario	Expected Result	Status
		✅/❌
		✅/❌
		✅/❌

Test Commands Run:

# Example: Run all tests
pytest

# Example: Run specific test file
pytest tests/test_api_v1/test_patient_routes.py -v

# Example: Run with coverage
pytest --cov=app

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)

Known Limitations / Technical Debt

Additional Notes

---

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