feat: rename Century badge to Active Volunteer, remove Elite badge, and award on attendence

Merge Request: Badge System Update

Overview

This MR updates the badge definitions in the EHRS application to better align with volunteer engagement goals. It removes the "Elite Volunteer" badge and renames the "Century Contributor" badge to "Active Volunteer".Updated badge awarding logic to trigger after attendance is recorded instead of after logout, ensuring badges are granted immediately upon visit completion.

What does this MR do and why?

The badge system is being refined to simplify the reward structure and use more intuitive naming.

• Removal of "Elite Volunteer": Streamlines the badge progression.
• Renaming "Century Contributor" to "Active Volunteer": Uses clearer terminology that is consistent with other badge names like "Consistent Volunteer" and "Certified Volunteer".

Changes Made

• app/services/badge_service.py:
  • Updated BADGE_DEFINITIONS to reflect the new set of badges.
  • Enhanced _ensure_badges_seeded to perform an in-place migration for existing databases:
    • Renames existing "Century Contributor" records to "Active Volunteer".
    • Deletes existing "Elite Volunteer" records.
• scripts/seed_database.py:
  • Updated seed_badges with the new badge definitions for consistent fresh environment setups.
• tests/test_services/test_badge_service.py:
  • Updated test cases to verify the removal and renaming logic.
• Updated badge awarding logic to trigger after attendance is recorded instead of after logout, ensuring badges are granted immediately upon visit completion.

Technical Details

The update uses a programmatic migration approach within the _ensure_badges_seeded helper. This ensures that when the application starts or the service is first invoked, the database state is automatically synchronized with the code's badge definitions without requiring a manual SQL migration for data-level changes in the badges table.

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

• Related to badge system refinement.

Screenshots or Screen Recordings

N/A (Backend logic changes)

How to Validate Locally

1. Check existing database state (if you have old badges):

   # Run the application or trigger badge evaluation
   # Verify in DB that 'Elite Volunteer' is gone and 'Century Contributor' is now 'Active Volunteer'

2. Run seed script:

   python scripts/seed_database.py --clear
   # Verify the new badges are created correctly

3. Verify via API:
   • Access the badges endpoint to see the updated list.

Testing Done

• Unit tests updated and passing.
• Verified badge seeding logic locally.

Test Cases Covered:

Scenario	Expected Result	Status
Rename Century Contributor	Badge name updated in DB	✅
Remove Elite Volunteer	Badge deleted from DB	✅
Seed fresh database	All 8 defined badges created	✅

Test Commands Run:

pytest tests/test_services/test_badge_service.py

Code Quality Checklist

Code Standards

• Code follows project conventions (naming, structure, formatting)
• No debug statements or commented-out code left
• No unused imports, variables, or functions
• No duplicate code
• Type hints are properly defined
• Ruff checks pass

Python & FastAPI Best Practices

• Functions follow single-responsibility principle
• Async/await used correctly
• Dependency injection used appropriately
• Pydantic models used for request/response validation
• SQLAlchemy queries are optimized
• Error handling is comprehensive

API Design

• RESTful conventions followed
• Proper HTTP status codes returned
• Input validation implemented
• Authentication/authorization enforced

Database & Migrations

• Database migrations handled via service logic for badge definitions
• Data integrity maintained during rename/delete

Security

• No sensitive data logged
• SQL injection prevention verified

Error Handling

• Errors are caught and handled gracefully
• User-friendly error messages returned

Documentation

• Code comments explain complex logic

Known Limitations / Technical Debt

None.

Additional Notes

The migration logic in _ensure_badges_seeded is idempotent and safe to run multiple times.

---

MR Acceptance Checklist

Quality & Correctness

• Code works as intended and solves the stated problem
• No bugs introduced
• 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