Comprehensive documentation of all data models in the Club app
Club App Data Models Documentation
Overview
This document provides a high-level overview of the data models in the Courtex Club application. The Club app is the central component for managing sports clubs, their members, sessions, and related activities.
Core Models
1. Club
The Club model represents a sports club or social group that organizes sessions and events.
Key Fields:
- uuid: Unique identifier for the club
- name: Club name
- description: Markdown-formatted description
- sport: Type of sport (Badminton, Tennis)
- location: Foreign key to Location model
- organiser: Many-to-many relationship with Users (club organizers)
- owned_by: Foreign key to User (club owner)
- favourited: Many-to-many relationship with Users who favorited the club
- visibility: Controls if/where listing appears (Public Directory, Private, Hidden)
- data_source: Origin of listing (Manual, Facebook, Other Public)
- is_unclaimed: Indicates if club was added by Courtex and not yet claimed
- use_club_rating: Indicates if club uses their own rating system
- rsvp_required: Whether RSVP is required for sessions
- website: Club website URL
- cancellation_policy: Club's cancellation policy text
Related Models:
- Member: Club members
- MembershipRequest: Pending membership requests
- ClubSchedule: Regular meeting schedule
- Session: Sessions hosted by the club
Business Logic:
- Automatically creates organizers as regular members via signal
- Supports markdown rendering for description
- Tracks ownership and claiming status
- Soft delete support via is_active flag
2. Member
The Member model represents a user's membership in a club.
Key Fields:
- uuid: Unique identifier
- club: Foreign key to Club
- user: Foreign key to User
- regular: Boolean indicating regular member status
- rating: Optional club-specific rating
Methods:
- change_regular(): Toggle regular member status
- change_rating(rating): Update member's rating
Business Logic: - Created automatically when a user becomes an organizer - Tracks member status within the club
3. MembershipRequest
The MembershipRequest model handles membership applications for clubs.
Key Fields:
- club: Foreign key to Club
- user: Foreign key to User
- accepted: Boolean or None (pending, accepted, rejected)
Methods:
- accept_request(): Approve membership request
- reject_request(): Deny membership request
Business Logic: - Automatically creates a Member record upon acceptance via signal - Three-state model: None (pending), True (accepted), False (rejected)
4. ClubSchedule
The ClubSchedule model defines regular meeting times for clubs.
Key Fields:
- club: Foreign key to Club
- day: Day of week (Mon, Tue, Wed, Thu, Fri, Sat, Sun)
- start_time: Session start time
- end_time: Session end time
Business Logic: - Multiple schedules can exist for one club (e.g., Monday and Wednesday sessions) - Provides regular schedule information for club members
Supporting Models
5. Location
The Location model represents physical venues where clubs and sessions are held.
Key Fields:
- name: Venue name
- address1, city, suburb, state, country, zip_code: Address information
- floor_type: Surface type (Wooden, Concrete, Synthetic, Other)
- badminton_mats_used: Boolean for mat availability
- sports_shop_exists: Boolean for on-site shop
- created_by: Foreign key to User
Business Logic: - Shared across clubs and sessions - Tracks venue amenities and characteristics - Linked to clubs and sessions via foreign keys