Club Management

A Club is an OrgNode anchored to its district through district_id. Its profile carries name, logo, venue, founding year, contact details, level (recreational, regional, national, international), a closed ClubFacility enum with 13 facility flags (indoor, outdoor, bar, parking, accessibility, etc.) and a free-text description capped at 5 000 characters. Board composition is structured — president, secretary, treasurer and additional roles — with multilingual token matching so has_president/has_secretary/has_treasurer flags work correctly across French, Swedish, German and English titles.

Affiliation runs as a yearly lifecycle: registered → affiliated → renewed/expired with days_until_expiry surfaced for renewal reminders. The member roster is the canonical list of users tied to the club; license issuance (F03) and competition entries (F04) all key off it. GET /clubs/{id}/statistics aggregates everything an operator wants to see on the club dashboard — member count, board completeness, affiliation status, hosted competitions split by status with first/last host date, published results — and every query goes through Beanie's typed query builder so user input cannot inject Mongo operators.

Club-to-club communication uses ClubMessage: messages are threaded (the root message's thread_id equals its own id, replies inherit the thread and auto-prefix Re:), cross-tenant sends are blocked with 403, and mark-read by the sender returns 400. Attachments are stored as metadata. The directory adds city/level/facility filters; facility uses MongoDB $all semantics so ?facility=indoor&facility=bar ANDs the conditions, backed by dedicated indexes on (level,1), (facilities,1) and (venue.city,1).

ClubDocument is a versioned document store with a closed category enum (statutes, bylaws, insurance, permit, financial_statement, meeting_minutes, policy, other), valid_from/valid_to validation, soft-delete, an expiring?days=N sweep and route ordering that places /documents/expiring before /documents/{document_id} to avoid collision. Safeguarding officer tracking embeds SafeguardingOfficer (user_id, contact, term, BackgroundCheck link, training status, contact_visible_publicly) on the club, with an append-only safeguarding_history; replacing the officer archives the previous one with end_reason=replaced and ended_at=now, and DELETE requires an end_reason in the body.