Fixed issue where active users list in event chat did not update in
real-time when new users joined. Users had to refresh the page to see
newly joined participants.
Root Cause:
- getAllDisplayUsers() used checkedInUsers (loaded once from API) as
base list, with activeUsers (Socket.IO real-time) only for isOnline flag
- When new user joined chat, they appeared in activeUsers but not in
checkedInUsers, so they were not displayed
Solution:
- Rewrote getAllDisplayUsers() to prioritize activeUsers (real-time data)
- Merges activeUsers (online) with checkedInUsers (offline checked-in users)
- Uses Socket.IO data as source of truth for online users
- Enriches with database data when available (firstName, lastName, etc)
- Sorts online users first, offline second
Changes:
- EventChatPage.jsx: Rewrote getAllDisplayUsers() to merge activeUsers
with checkedInUsers, prioritizing real-time Socket.IO data
- useEventChat.js: Added debug logging for active_users events
- socket/index.js: Added debug logging for active_users emissions
Testing:
- User A in chat sees User B appear immediately when B joins
- No page refresh required
- Online/offline status updates in real-time
Updated all major documentation files to reflect the completed Activity
Log System (Phase 3.5) implementation.
Changes:
- README.md: Added Admin & Monitoring section, updated database schema
to 12 tables, added Activity Log System to completed phases, updated
project structure to show admin pages and services
- SESSION_CONTEXT.md: Updated recent work, added activity log system to
core features, updated database schema, added comprehensive Phase 3.5
overview with all implementation details
- COMPLETED.md: Added full Activity Log System entry with all 8 phases,
implementation details, git commits, and access information
Updated dates to 2025-12-02.
Complete implementation of admin activity logs dashboard with real-time
streaming capabilities. Admin users can now monitor all system activity
through a comprehensive web interface.
Features:
- Stats dashboard with 4 key metrics (total logs, unique users, failures, 24h activity)
- Category breakdown visualization with color-coded badges
- Advanced filtering (date range, category, action type, username, success/failure)
- Paginated log table (50 entries per page) with sort by timestamp
- Real-time streaming toggle using Socket.IO
- Color-coded action badges (blue=auth, green=event, purple=match, red=admin, yellow=chat)
- Admin-only access with automatic redirect for non-admin users
- Responsive design for mobile and desktop
Frontend Changes:
- Created ActivityLogsPage.jsx (600+ lines) with complete UI implementation
- Added 3 admin API methods to api.js (getActivityLogs, getActivityLogActions, getActivityLogStats)
- Added /admin/activity-logs route to App.jsx
- Added admin navigation link to Navbar (desktop & mobile) with Shield icon
- Only visible to users with isAdmin flag
Implementation Details:
- Uses getSocket() from socket service for real-time updates
- Joins 'admin_activity_logs' Socket.IO room on streaming enable
- Receives 'activity_log_entry' events and prepends to table (first page only)
- Comprehensive error handling and loading states
- Empty states for no data
- Clean disconnect handling when streaming disabled
Testing:
- Build successful (no errors)
- Ready for manual testing and verification
Phase 8 (Testing) remains for manual verification of all features.
Added 3 admin-only endpoints for activity log management:
1. GET /api/admin/activity-logs
- Query logs with comprehensive filtering
- Supports: date range, action, category, username, userId, success
- Pagination with limit/offset
- Logs ADMIN_VIEW_LOGS action
- Returns: logs array, total count, pagination info
2. GET /api/admin/activity-logs/actions
- Get list of unique action types
- Returns: action names and categories
- Useful for filter dropdowns in UI
3. GET /api/admin/activity-logs/stats
- Dashboard statistics
- Returns: total logs, unique users, failed actions,
success rate, logs by category, recent activity (24h)
All endpoints protected with authenticate + requireAdmin middleware.
Database changes:
- Add ActivityLog model for comprehensive activity tracking
- Track all user actions (auth, events, matches, admin)
- Denormalized username for query performance
- JSON metadata for flexibility
- Multiple indexes for common filter patterns
- Add isAdmin flag to User model for admin access control
- Add activityLogs relation to User
Schema pushed to database with prisma db push
Created initial admin user: spotlight@radziel.com
This is Phase 1 of Activity Log System implementation.
Next phases: backend service, middleware, API endpoints, frontend UI.
- Move email templates to separate files in src/emails/templates/
- Create new email service architecture (service.js, index.js)
- Add recording suggestions email template for matching notifications
- Integrate email notifications with matching system (sends when suggestions created)
- Update controllers (auth.js, user.js) to use new email module
- Update tests to use new email module path
- Remove deprecated src/utils/email.js
Features:
- Template-based email system for easy editing
- Automatic email notifications when recording assignments are made
- Clean separation between template logic and sending logic
- Graceful error handling for AWS SES failures
S15.1-15.2: Rate Limiting & Spam Protection
- Add max 20 pending outgoing match requests limit
- Implement rate limiter: 10 match requests per minute per user
- Return 429 status with clear error messages
S16.1: Socket Notifications for New Suggestions
- Emit 'recording_suggestions_created' event when matching creates suggestions
- Notify only assigned recorders (not NOT_FOUND status)
- Group suggestions by recorder for efficiency
- Include event details and suggestion count
Implementation:
- backend/src/routes/matches.js: Rate limiter + pending limit check
- backend/src/services/matching.js: Socket notifications in saveMatchingResults
- backend/src/__tests__/spam-protection-notifications.test.js: 8 test cases
Test coverage:
- TC1-TC3: Max pending requests (spam protection)
- TC4-TC5: Rate limiting (10/min)
- TC6-TC8: Socket notifications for new suggestions
- Update README.md with current test statistics (342/342 tests passing)
- Add detailed breakdown of all matching/ratings test suites
- Create comprehensive TESTING_MATCHING_RATINGS.md guide covering all 45 tests
- Document matching runs audit, incremental matching, and scheduler features
- Add code coverage highlights and test scenarios
- Updated event_message test to expect message.user.username
- Matches current socket.io implementation which nests user data
- All 342 tests now passing (100%)
Backend:
- Extend GET /api/matches to include RecordingSuggestions alongside Match objects
- Add 'type' field: 'manual' for user-created matches, 'auto' for algorithm suggestions
- Fetch suggestions where user is dancer (to be recorded) or recorder (recording others)
- Transform suggestions to match format with partner info
- Support status filtering for both types
Frontend:
- Display 'Auto' (purple) or 'Manual' (gray) badge on match cards
- For pending auto suggestions: show 'Go to Records' button instead of Accept/Reject
- For accepted auto suggestions without slug: show 'Chat not available yet'
- Only allow Accept/Reject actions on manual match requests
- Extend dashboard API to include recordingSuggestions for each event
- Add toBeRecorded and toRecord arrays with heat and user details
- Export RecordingSummaryCard component
- Add Recording Assignments section to DashboardPage
- Filter and display events with recording suggestions
- Show up to 2 suggestions per event with View Details link
- Increase font size from xs to sm for better readability
- Reduce avatar size from xs to 24px for better proportions
- Add proper layout with heat names in separate line
- Add truncate for long usernames to prevent overflow
- Style status badges with colored backgrounds and icons (pending/accepted)
- Fix EventChatPage to read and handle ?tab=records URL parameter
- Map 'records' query param to 'recording' tab for proper navigation
Backend changes:
- Restrict suggestion status updates to recorder only
- Dancers can now only view who is assigned to record them
- Return 403 error if non-recorder tries to update status
Frontend changes:
- Remove Accept/Reject buttons from dancer view (TO_BE_RECORDED)
- Add "Pending" status badge with clock icon for pending suggestions
- Keep Accept/Reject buttons for recorder view (TO_RECORD)
- Dancers see only status badge and optional chat button
UX flow:
- Dancer sees: "Recording you: @username [Pending]"
- Recorder sees: "You record: @username [Accept] [Reject]"
- Only recorder's action creates the Match
- Admin list endpoint returns totalSuggestions, assignedCount, aggregatedNotFoundCount per run
- UI: show Total/Matched/Not found columns using fresh aggregates
- Add anchor link Run #ID and wording 'Pairs created in this run'
- Extend saveMatchingResults(eventId, suggestions, runId) and set originRunId
- Scheduler/Admin run-now: always pass runId
- Admin API: GET /api/admin/events/:slug/matching-runs/:runId/suggestions
- Prisma: add compound index on (origin_run_id, status)
- Frontend: add getRunSuggestions, expand row in MatchingRunsSection with 'Pairs created in this run' wording
- New adminAPI for run-now and runs listing
- MatchingRunsSection with refresh and run controls
- Integrate into EventDetailsPage under matching configuration
- Add in-process scheduler service triggered by ENABLE_SCHEDULER
- Record runs in new matching_runs table; throttle per-event and log stats
- Add admin endpoints: POST /api/admin/events/:slug/run-now and GET /api/admin/events/:slug/matching-runs
- Wire scheduler start/stop in server and add ENV flags + compose defaults
- Prisma schema: add MatchingRun model and relation
- Update env examples for scheduler configuration
Backend changes:
- Modified getUserSuggestions to include match data (id, slug, status)
- Returns match info for both toBeRecorded and toRecord suggestions
Frontend changes:
- Added useNavigate hook to RecordingTab
- Capture match data from updateSuggestionStatus response
- Added MessageCircle icon and chat button to SuggestionCard
- Show "Open Chat" button for accepted suggestions with active matches
- Navigate to /matches/{matchSlug}/chat when clicked
This completes the recording stats flow by allowing users to easily
access the match chat after accepting a recording suggestion.
Fix race conditions and edge cases in recording stats update mechanism:
1. Race condition prevention:
- Use atomic updateMany with statsApplied=false condition in rating endpoint
- Prevents duplicate stats increments when both users rate concurrently
- Only one request wins the race and applies stats (matches.js:834-843)
2. Multiple heats handling:
- Check for existing Match by (user1Id, user2Id, eventId) instead of suggestionId
- Ensures one Match per dancer-recorder pair regardless of number of heats
- Reuses existing Match and chat room (events.js:1275-1291)
3. Documentation improvements:
- Add comprehensive JSDoc explaining manual vs auto-match design decision
- Clarify fairness metrics measure algorithmic assignments, not voluntary collaborations
- Document user role convention (user1=dancer, user2=recorder)
Edge cases are verified through atomic operations and code review rather than
complex integration tests to maintain test clarity and reliability.
Test Results: 304/305 tests passing (99.7%)
Coverage: 74.63% (+0.1%)
Add automatic tracking of recording statistics (recordingsDone/recordingsReceived)
for users participating in auto-matched collaborations. Stats are updated when
both users complete mutual ratings after a recording session.
Changes:
- Add suggestionId, source, and statsApplied fields to Match model
- Implement applyRecordingStatsForMatch() helper with user role convention
(user1 = dancer, user2 = recorder)
- Update suggestion status endpoint to create Match on acceptance
- Update ratings endpoint to apply stats when match is completed
- Add comprehensive unit tests (5) and integration tests (5)
Convention: Stats only updated for auto-matches (source='auto') to ensure
fairness metrics reflect actual algorithmic assignments, not manual matches.
Test Results: 304/305 tests passing (99.7%)
Coverage: 74.53% (+1.48%)
- Export getPostDanceBufferSlots and HEAT_BUFFER_AFTER for testing
- Add direct tests for getPreDanceBufferSlots (4 tests)
- Add direct tests for getPostDanceBufferSlots (2 tests)
- Add test for HEAT_BUFFER_AFTER constant
- Add edge case for getCoverableHeats with multiple recorder heats
- Add edge case for hasCollision with multi-heat scenarios
- Total: 39/39 tests passing (9 new tests added)
- Update README.md with tier system and recent features
- Add 3-tier account system (BASIC/SUPPORTER/COMFORT) to docs
- Document fairness algorithm and dual buffer system
- Add clickable usernames and country flags features
- Update test count to 285/286 passing (99.7%)
- Update database schema documentation with tier fields
- Update all last modified dates to 2025-11-29
- Add dual buffer system: BEFORE (prep) and AFTER (rest) dancing
- Track recording assignments to prevent double-booking recorders
- Fix sorting priority: location score takes precedence over load balancing
- Simplify opt-out logic with complete exclusion from matching pool
- Buffers apply only to dancing heats, not recording assignments
- Improve documentation clarity for algorithm constraints
- Updated all profile links to use /@username format
- Made usernames clickable in chat messages
- Added URL parameter sanitization to strip @ when fetching user data
- Ensures consistent profile URL format across the application
Implemented display of country flags and competitor numbers in event chat messages:
- Country flags displayed as emoji (🇸🇪, 🇵🇱, etc.) with proper emoji font support
- Competitor numbers shown in #123 format next to usernames
- Normalized data architecture with user and participant caches on frontend
- User data (username, avatar, country) and participant data (competitorNumber) cached separately
- Messages store only core data (id, content, userId, createdAt)
- Prevents data inconsistency when users update profile information
- Fixed duplicate message keys React warning with deduplication logic
- Backend sends nested user/participant objects for cache population
- Auto-updates across all messages when user changes avatar or country
Backend changes:
- Socket.IO event_message and message_history include nested user/participant data
- API /events/:slug/messages endpoint restructured with same nested format
- Batch lookup of competitor numbers for efficiency
Frontend changes:
- useEventChat hook maintains userCache and participantCache
- ChatMessage component accepts separate user/participant props
- ChatMessageList performs cache lookups during render
- Emoji font family support for cross-platform flag rendering
Add test-bot.js script that simulates a user participating in event chat for testing purposes.
Features:
- Authenticates as user via API
- Checks in to event using QR code token
- Connects to Socket.IO and joins event room
- Sends random messages at configurable intervals
- Auto-accepts recording suggestions
Usage from container:
docker compose exec backend sh -c 'API_URL=http://localhost:3000 node scripts/test-bot.js --email user@example.com --password pass --slug event-slug --interval 10'
- Save vertical space on mobile by showing page title in navbar
- Mobile: "spotlight.cam - {PageTitle}" instead of separate h1
- Desktop: unchanged - page titles remain as separate headings
- Saves ~60-80px vertical space on mobile devices
Pages updated:
- Dashboard, Events, Matches, History, Profile
- Add w-full to MatchCard for consistent card width
- Use Layout noPadding to avoid padding conflicts
- Add explicit padding and width control to main container
- Ensure All, Pending, and Active tabs have identical width
- Show error alert when login fails instead of console-only logging
- Display user-friendly error message: "Invalid email or password"
- Clear error state before new login attempt
- Use existing Alert component for consistency with RegisterPage
- Replace "Edit heats" button with icon-only version
- Remove connection status indicator (show "Disconnected" warning only when offline)
- Remove event location from header
- Hide Participants tab on desktop (sidebar already visible)
- Remove "Participants" header from sidebar on desktop
