Recognition Tier Repository
Component Detail
Description
Data access layer for recognition tier definitions and awarded tier records. Manages both the tier catalog (Coordinator of the Year, seasonal awards) and the assignment records linking users to tiers with award periods.
recognition-tier-repository
Summaries
The Recognition Tier Repository powers the organisation's structured awards program by reliably storing and surfacing tier definitions — such as Coordinator of the Year and seasonal honours — alongside every individual assignment record. This creates a permanent, auditable recognition history that strengthens volunteer retention and program credibility. By centralising tier data, the organisation can consistently deliver meaningful recognition moments without manual coordination overhead, reducing administrative burden and reinforcing the culture of appreciation that keeps peer mentors engaged and motivated over time.
This is a low-complexity backend data component with no external dependencies, making it a low-risk, early-deliverable item in the project schedule. It underpins the coordinator dashboard and any tier-display features, so it must be completed before those consumer components enter development. Testing requirements are straightforward: unit tests for each query method and integration tests against a seeded database covering active-assignment lookups and multi-organisation data isolation. Estimated delivery is 1–2 sprint days.
No third-party integrations create scheduling risk, though schema migrations should be versioned carefully from day one.
Implements the data access layer for the recognition_tier data model, exposing five typed repository methods over a backend persistence store (likely Supabase/PostgreSQL given the project stack). Key patterns include organisation-scoped queries to prevent cross-tenant data leakage, nullable return for findActiveAssignment to cleanly signal absence, and atomic insert/delete for assignment lifecycle. No upstream dependencies means this can be implemented and tested in isolation. Callers should expect List
Consider adding an index on (userId, organisationId) for performant active-assignment lookups at scale.
Responsibilities
- Store and retrieve tier definitions per organisation
- Manage tier assignment records with award periods
- Query active tier for a given user
- Support coordinator dashboard tier overview
Interfaces
findTierDefinitions(String organisationId) -> List<RecognitionTier>
findActiveAssignment(String userId) -> TierAssignment?
insertAssignment(TierAssignment assignment) -> TierAssignment
deleteAssignment(String assignmentId)
findAllAssignments(String organisationId) -> List<TierAssignment>
Relationships
Dependents (2)
Components that depend on this component