thrillwiki_django_no_react/BACKEND_STRUCTURE.md

Backend Structure Plan

Apps Overview

1. apps.core

• Responsibility: Base classes, shared utilities, history tracking.
• Existing: SluggedModel, TrackedModel.
• Versioning Strategy (Section 15):
  • All core entities (Park, Ride, Company) must utilize django-pghistory or apps.core tracking to support:
    • Edit History: Chronological list of changes with reason, user, and diff.
    • Timeline: Major events (renames, relocations).
    • Rollback: Ability to restore previous versions via the Moderation Queue.

2. apps.accounts

• Responsibility: User authentication, profiles, and settings.
• Existing: User, UserProfile (bio, location, home park).
• Required Additions (Section 9):
  • UserDeletionRequest: Support 7-day grace period for account deletion.
  • Privacy Settings: Fields for is_profile_public, show_location, show_email on UserProfile.
  • Data Export: Serializers/Utilities to dump all user data (Reviews, Credits, Lists) to JSON.

3. apps.parks

• Responsibility: Park management.
• Models: Park, ParkArea.
• Relationships:
  • operator: FK to apps.companies.Company (Type: Operator).
  • property_owner: FK to apps.companies.Company (Type: Owner).

4. apps.rides

• Responsibility: Ride data, Coasters, and Credits.
• Models:
  • Ride: Core entity (Status FSM: Operating, SBNO, Closed, etc.).
  • RideModel: Defines the "Type" of ride (e.g., B&M Hyper V2).
  • Manufacturer: FK to apps.companies.Company.
  • Designer: FK to apps.companies.Company.
• Ride Credits (Section 10):
  • Model: RideCredit (Through-Model: User <-> Ride).
  • Fields:
    • count (Integer): Total times ridden.
    • rating (Float): Personal rating (distinct from public Review).
    • first_ridden_at (Date): First time experiencing the ride.
    • notes (Text): Private personal notes.
  • Constraints: Unique(user, ride) - A user has one credit entry per ride.

5. apps.companies

• Responsibility: Management of Industry Entities (Section 4).
• Models:
  • Company: Single model with type choices or Polymorphic.
  • Types: Manufacturer, Designer, Operator, PropertyOwner.
  • Features: Detailed pages, hover cards, listing by type.

6. apps.moderation (The Sacred Submission Pipeline)

• Responsibility: Centralized Content Submission System (Section 14, 16).
• Concept: Live Data (Approve) vs Submission Data (Pending).
• Models:
  • Submission:
    • submitter: FK to User.
    • content_type: Target Model (Park, Ride, etc.).
    • object_id: Target ID (Null for Creation).
    • data: JSONField storing the proposed state.
    • status: State Machine (Pending -> Claimed -> Approved | Rejected | ChangesRequested).
    • moderator: FK to User (Claimaint).
    • moderator_note: Reason for rejection/feedback.
  • Report: User flags on content.
• Workflow:
  1. User submits form -> Submission created (Status: Pending).
  2. Moderator Claims -> Status: Claimed.
  3. Approves -> Applies data to Live Model -> Saves Version -> Status: Approved.

7. apps.media

• Responsibility: Media Management (Section 13).
• Models:
  • Photo: GenericFK. Fields: image, caption, user, status (Moderation).
  • Banner/Card: Entities should link to a "Primary Photo" or store a cached image field.

8. apps.reviews

• Responsibility: Public Reviews & Ratings (Section 12).
• Models:
  • Review: GenericFK (Park, Ride).
  • Fields: rating (1-5, 0.5 steps), title, body, helpful_votes.
  • Logic: Aggregates (Avg Rating, Count) calculation for Entity caches.

9. apps.lists

• Responsibility: User Lists & Rankings (Section 11).
• Models:
  • UserList: Title, Description, Type (Park/Ride/Coaster/Mixed), Privacy (Public/Private).
  • UserListItem: FK to List, GenericFK to Item, Order, Notes.

10. apps.blog

• Responsibility: News & Updates.
• Models: Post, Tag.

11. apps.support

• Responsibility: Human interaction.
• Models: Ticket (Contact Form).