thrilltrack-explorer/PHASE_2_REPORTS_INTEGRATION_COMPLETE_WITH_REMAINING_WORK.md

Phase 2: Reports Component Integration - Status Report

Completed ✅

Successfully migrated all direct reports queries from Supabase to Django API:

1. ReportButton.tsx

• ✅ Report submission now uses reportsService.submitReport()
• ✅ Removed direct Supabase reports insert
• ✅ Uses ServiceResponse pattern for error handling

2. useModerationStats.ts

• ✅ Report statistics now use reportsService.getStatistics()
• ✅ Removed Supabase reports count queries
• ✅ Maintained polling for updates

3. ReportsQueue.tsx

• ✅ Report listing now uses reportsService.listReports()
• ✅ Report status updates now use reportsService.updateReportStatus()
• ✅ Pagination uses Django format (page/page_size)

Remaining Supabase Dependencies ⚠️

The components still use Supabase for:

In ReportsQueue.tsx:

1. Reporter Profile Data (Lines ~195-210)

   const { data: allProfiles } = await supabase.rpc('get_users_with_emails');
   // OR
   await supabase.from('profiles').select('user_id, username, display_name')
   

   Solution needed: Django users/profiles API endpoint + service layer

2. Related Content Queries (Lines ~219-258)

   • Reviews: supabase.from('reviews').select(...)
   • Profiles: supabase.rpc('get_users_with_emails')
   • Submissions: supabase.from('content_submissions').select(...)

   Solution needed: Django API endpoints + service layers for:

   • Reviews API (partial - may exist in api/v1/endpoints/reviews.py)
   • Profiles API (partial - may exist in api/v1/endpoints/auth.py)
   • Content submissions API (needs investigation)

3. Audit Logging (Lines ~385-401)

   await supabase.rpc('log_admin_action', {...})
   

   Solution needed: Django audit logging endpoint + service layer

In useModerationStats.ts:

1. Content Submissions Stats (Line ~81-84)

   await supabase.from('content_submissions')
     .select('id', { count: 'exact', head: true })
     .eq('status', 'pending')
   

2. Flagged Reviews Stats (Line ~86-89)

   await supabase.from('reviews')
     .select('id', { count: 'exact', head: true })
     .eq('moderation_status', 'flagged')
   

Required Next Steps for Full Migration

Phase 2B: Complete Reports Supabase Removal

Step 1: Create Service Layers

Need to create service layers similar to reports service for:

1. Users/Profiles Service (src/services/users/)

   • getUserProfile(userId)
   • getUserProfiles(userIds[]) - batch fetch
   • getUsersWithEmails() - admin function

2. Reviews Service (src/services/reviews/)

   • getReview(reviewId)
   • getReviews(reviewIds[]) - batch fetch
   • May already partially exist

3. Submissions Service (src/services/submissions/)

   • getSubmission(submissionId)
   • getSubmissions(submissionIds[]) - batch fetch
   • getSubmissionStats() - for moderation stats

4. Audit Service (src/services/audit/)

   • logAdminAction(action, details)

Step 2: Verify Django Endpoints Exist

Check if these Django endpoints exist and are complete:

• GET /api/v1/users/{id} - Single user profile
• GET /api/v1/users/ - Batch user profiles (with query params)
• GET /api/v1/reviews/{id} - Single review
• GET /api/v1/reviews/ - Batch reviews
• GET /api/v1/submissions/{id} - Single submission
• GET /api/v1/submissions/ - Batch submissions
• GET /api/v1/submissions/stats - Submission statistics
• POST /api/v1/audit/log - Log admin action

Step 3: Update Components

Once service layers exist:

1. Update ReportsQueue.tsx:

   • Replace Supabase profile queries with users service
   • Replace Supabase content queries with respective services
   • Replace Supabase audit logging with audit service

2. Update useModerationStats.ts:

   • Replace Supabase submission stats with submissions service
   • Replace Supabase review stats with reviews service

3. Remove Supabase import from both files

Step 4: Update Realtime Strategy

Since Django doesn't support realtime subscriptions:

• Convert all realtime subscriptions to polling
• Or use WebSockets if Django has them configured
• Or use Server-Sent Events (SSE) if available

Current Architecture

What's Using Django API ✅

ReportButton → reportsService → Django Reports API
useModerationStats → reportsService.getStatistics() → Django Reports API
ReportsQueue → reportsService.listReports() → Django Reports API
ReportsQueue → reportsService.updateReportStatus() → Django Reports API

What's Still Using Supabase ⚠️

ReportsQueue → Supabase → profiles (reporter data)
ReportsQueue → Supabase → reviews (reported content)
ReportsQueue → Supabase → profiles (reported profiles)
ReportsQueue → Supabase → content_submissions (reported submissions)
ReportsQueue → Supabase RPC → audit logging

useModerationStats → Supabase → content_submissions (stats)
useModerationStats → Supabase → reviews (flagged count)
useModerationStats → Supabase realtime → submissions updates
useModerationStats → Supabase realtime → reviews updates

Estimated Effort for Full Migration

• Step 1 (Service Layers): 3-4 hours
• Step 2 (Verify Endpoints): 1 hour
• Step 3 (Update Components): 2-3 hours
• Step 4 (Realtime Strategy): 1-2 hours
• Testing: 2-3 hours

Total: ~10-15 hours

Recommendation

Option A - Complete Now: Proceed with creating all necessary service layers and complete the full Supabase removal.

Option B - Iterative Approach:

1. Complete Phase 2B separately (remove remaining Supabase from reports components)
2. Then tackle other components in subsequent phases
3. Allows for testing and validation at each step

Option C - Hybrid Temporary State: Keep current partial migration working while planning full migration, as:

• Reports CRUD is fully on Django (main goal achieved)
• Related content queries are working (though via Supabase)
• Can be migrated incrementally without breaking functionality

Decision Point

Choose one of the above options to proceed. Current state is functional but not fully migrated from Supabase.