Post-Session Report Repository
Component Detail
Description
Handles all CRUD operations for post-session report records in Supabase. Ensures every report is stored with its parent activity_id foreign key. Provides queries for coordinator views of submitted reports by activity and by peer mentor.
post-session-report-repository
Summaries
The Post-Session Report Repository is the organisation's system of record for all peer mentor activity outcomes. By reliably persisting every submitted report and linking it to its parent activity, this component ensures that coordinators always have accurate, queryable data to assess mentor performance, track session delivery, and produce evidence for funders. Without this layer, reporting data would be fragmented or lost, undermining program evaluation and grant compliance. Its draft-save capability also reduces abandonment risk — mentors can start a report, save progress, and return later — directly improving submission rates and reducing coordinator follow-up burden, which translates to measurable staff time savings.
Post-Session Report Repository is a medium-complexity data component spanning both mobile and backend execution contexts, which introduces coordination overhead between client-side and Supabase database work. Development effort should account for schema alignment with the post-session-report and activity data models, including foreign key constraints and row-level security policies in Supabase. The submitReport operation needs a clear state-machine definition (draft → submitted) agreed with the product owner before implementation. Testing must cover both the mobile SDK calls and direct backend query paths used by coordinator views.
Plan for integration testing with the Report Field Validator and the coordinator dashboard. A potential scheduling risk is Supabase RLS policy configuration, which requires database admin access and should be allocated to a developer with prior Supabase experience.
Post-Session Report Repository abstracts all Supabase persistence operations for post-session reports behind a clean seven-method interface. createReport(activityId, fields) inserts a new draft record with the activity_id foreign key enforced at the database level, preventing orphaned reports. getReportsByActivity(activityId) and getReportsByPeerMentor(mentorId) support coordinator-facing query patterns and should be implemented with appropriate Supabase RLS policies so coordinators only access reports within their scope. submitReport(reportId) transitions a draft to a submitted state — implement this as an atomic update toggling a status column with a server-side timestamp.
The component runs in both mobile (Supabase JS client) and backend (Supabase service role) contexts; keep the interface identical across both and inject the client as a dependency to simplify testing and context switching.
Responsibilities
- Create new report records linked to activity_id
- Read reports by activity, by peer mentor, or by coordinator
- Update draft report fields before final submission
- Delete draft reports on user cancellation
Interfaces
createReport(activityId, fields)
getReport(reportId)
getReportsByActivity(activityId)
getReportsByPeerMentor(mentorId)
updateReport(reportId, fields)
deleteReport(reportId)
submitReport(reportId)
Relationships
Related Data Entities (2)
Data entities managed by this component
Used Integrations (1)
External integrations and APIs this component relies on