Reservations

API fact source: Django backend generated docs

Why Reservations Are Modeled Separately

borrowings owns manual reservation applications, approval routing, cancellation, and reservation rescheduling. It does not own course facts; it references course occurrences for conflict checks and course-derived reservation cases.

Code entry:

• backend/apps/borrowings/models/
• backend/apps/borrowings/views/
• backend/apps/borrowings/services/

Approval Routing

List visibility and available actions are routed by current_role, not by a simple admin/non-admin split. activity_type determines first review: student activities go to counselor, teaching activities go to secretary. Second review belongs to assistant; superadmin can grant final approval directly.

Conflict checks cover both manual reservations and CourseOccurrence. A change that checks only manual reservations can place a reservation on top of a scheduled class.

Similar Actions With Different Meaning

Course reservation rescheduling and course occurrence rescheduling are different actions. source_type=course records come from course scenarios and are not equivalent to manual reservations. Cancellation currently has a 6-hour-before-start restriction, which is user-visible behavior.

State-Machine Impact

• When adding statuses or approval branches, update list filtering, permission checks, operation logs, and frontend pending-task views.
• Self-review rule changes need an explicit decision on whether the assistant / superadmin exceptions still apply.
• Submit-on-behalf-of behavior is limited to privileged roles and preserves the applicant identity.