Check-ins

API fact source: Django backend generated docs

Why Check-Ins Attach To Course Occurrences

checkins owns check-in sessions and student records for course occurrences. It depends on course and user class data and does not maintain an independent schedule system.

Code entry:

• backend/apps/checkins/models/
• backend/apps/checkins/views/
• backend/apps/checkins/serializers/
• backend/apps/checkins/services/

Sessions And Rosters

Check-in sessions attach to CourseOccurrence, and creating a session for the same occurrence is idempotent. This keeps teachers, students, signage devices, and course queries aligned on the same class-session fact.

Rosters are derived by matching course class names to user student_class. That string-based match means course class fields and user class fields affect check-in coverage.

Non-admin users can only manage check-in data for their own courses; students can only see their own check-ins and schedule.

Time-Dependent Behavior

• Automatic status transitions depend on class period times, timezone behavior, and the frontend daily view.
• Check-in status is time-dependent; tests cover boundary times.

Reserved Capabilities

• A new check-in method needs method, source, confidence, and operation-log behavior.
• Signage devices do not currently write check-ins. Adding that requires device identity, student identity, and replay protection.
• Face-recognition fields exist, but face-service is not yet part of the main check-in flow.