Documentation of all data models in the Locations app

Locations App Data Models Documentation

Brand values alignment: All features and data models should align with Courtex values: Community, Transparency, Accessibility, Integrity, Humility. See docs/markdown/brand/copilot-instructions.md for full guidance.

Overview

The Locations app manages physical venues and facilities where sports clubs host their sessions. Location records are shared across clubs and sessions.

Core Models

1. Location

The Location model represents a physical sports facility or venue where clubs and sessions are held.

Key Fields: - name: Venue name - address1: Street address - city: City (optional) - suburb: Suburb/neighbourhood - state: State/region (optional) - country: Country - zip_code: Postcode/ZIP code (optional) - floor_type: Surface type; one of wooden, concrete, synthetic, or other (optional) - badminton_mats_used: Boolean indicating whether badminton mats are used at this venue - sports_shop_exists: Boolean indicating whether there is an on-site sports shop - created_by: Foreign key to User who added this location (nullable; SET_NULL on delete) - created_date: Auto-set timestamp when the record was created - modified_date: Auto-updated timestamp whenever the record is saved

Meta: - verbose_name = 'location' - verbose_name_plural = 'locations'

Business Logic: - Locations are shared resources — a single Location can be linked to many clubs and many sessions - floor_type is relevant for badminton clubs (wooden vs. synthetic courts have different characteristics) - badminton_mats_used helps players know whether they need to bring mat-appropriate footwear - The created_by field tracks who submitted the location entry

Related Models: - clubs.Club: A club may have a location foreign key pointing to this model - sport_sessions.Session: A session may have a location foreign key pointing to this model - sport_sessions.SessionTemplate: A session template may also reference a location

Notes

  • The Location model does not inherit from TimeStampedModel; it uses its own created_date and modified_date fields
  • There is no soft-delete on locations; deletion is permanent
  • Location data may be sourced manually or from public sources (as tracked by clubs.ClubDataSource)