Cas d'utilisation — Clubs & Terrains¶

Ce document détaille les cas d'utilisation du domaine Clubs.

CU-CLUB-01 — Inscrire un nouveau club¶

Scénario principal¶

1. L'utilisateur accède au formulaire d'inscription de club.
2. Il renseigne le nom, l'adresse et la ville (obligatoires), ainsi que les champs optionnels (téléphone, email, site web, description).
3. Le système crée le club avec le statut pending.
4. Si l'utilisateur est player, son rôle passe à club_manager.
5. Les administrateurs reçoivent une notification club_registration_received.
6. L'utilisateur est redirigé vers la page de gestion de son club.

Scénario alternatif — Validation échouée¶

• Si des champs obligatoires sont manquants ou invalides, le formulaire affiche les erreurs de validation (422).

CU-CLUB-02 — Revendiquer un club existant¶

Scénario principal¶

1. L'utilisateur recherche dans la liste des clubs sans propriétaire.
2. Il sélectionne un club et le revendique.
3. Le système attribue le club à l'utilisateur et passe le statut à pending.
4. Les administrateurs sont notifiés.

Scénario alternatif — Club déjà revendiqué¶

• Si le club a déjà un propriétaire, le système retourne une erreur 409 (Conflict).

CU-CLUB-03 — Consulter la fiche d'un club¶

Scénario principal¶

1. L'utilisateur ouvre la fiche d'un club depuis la liste ou un lien.
2. Le système affiche les informations du club, ses coordonnées et ses terrains actifs.
3. L'utilisateur peut naviguer entre les onglets : Infos, Terrains, Parties.
4. Si authentifié, il peut ajouter/retirer le club de ses favoris.

CU-CLUB-04 — Gérer les terrains d'un club¶

Scénario principal — Ajouter un terrain¶

1. Le gestionnaire accède à la page Terrains de son club.
2. Il clique sur le bouton d'ajout (+).
3. Il renseigne le nom, le type, la description, le prix horaire et le statut actif.
4. Le système enregistre le terrain et rafraîchit la liste.

Scénario principal — Modifier un terrain¶

1. Le gestionnaire clique sur « Modifier » sur un terrain existant.
2. Il modifie les informations souhaitées.
3. Le système enregistre les modifications.

Scénario principal — Supprimer un terrain¶

1. Le gestionnaire clique sur « Supprimer » sur un terrain.
2. Une confirmation est demandée.
3. Le système supprime le terrain définitivement.

Scénario alternatif — Non autorisé¶

• Si l'utilisateur n'est pas le propriétaire du club, le système retourne une erreur 403.

CU-CRENEAU-01 — Gérer les créneaux horaires du club¶

Scénario principal — Ajouter un créneau¶

1. Le gestionnaire accède à la page Créneaux de son club.
2. Il sélectionne un jour de la semaine (0=Lundi … 6=Dimanche).
3. Il remplit le formulaire : heure de début, heure de fin, durée, terrain optionnel.
4. Le système enregistre le créneau et l'affiche dans le planning.

Scénario principal — Modifier un créneau¶

1. Le gestionnaire clique sur l'icône de modification d'un créneau existant.
2. Il modifie les informations souhaitées.
3. Le système enregistre les modifications.

Scénario principal — Marquer indisponible¶

1. Le gestionnaire bascule le toggle disponibilité sur un créneau.
2. Le système passe is_available à false.
3. Le créneau n'est plus proposé à la réservation.

Scénario principal — Supprimer un créneau¶

1. Le gestionnaire clique sur l'icône de suppression.
2. Une confirmation est demandée.
3. Le système supprime le créneau définitivement.

Scénario alternatif — Non autorisé¶

• Si l'utilisateur n'est pas le propriétaire du club, le système retourne une erreur 403.

CU-CRENEAU-02 — Consulter les créneaux d'un club¶

Scénario principal¶

1. L'utilisateur accède à la fiche d'un club.
2. Le système retourne les créneaux (GET /api/v1/clubs/{club}/creneaux).
3. L'utilisateur peut filtrer par jour de la semaine.

CU-RESERVATION-01 — Créer une demande de réservation¶

Scénario principal¶

1. Le joueur sélectionne un terrain et une plage horaire.
2. Il soumet le formulaire (POST /api/v1/clubs/{club}/reservations).
3. Le système vérifie l'absence de conflit (aucune réservation pending/accepted sur le même terrain au même horaire).
4. La réservation est créée avec le statut pending.
5. Le gestionnaire reçoit une notification.

Scénario alternatif — Conflit détecté¶

• Si un conflit existe, le système retourne une erreur 409.

CU-RESERVATION-02 — Traiter une demande de réservation (gestionnaire)¶

Scénario principal — Accepter¶

1. Le gestionnaire consulte la liste des réservations (filtrée sur pending).
2. Il clique sur « Accepter » pour une réservation.
3. Le système passe le statut à accepted.
4. Le joueur reçoit une notification reservation_accepted.

Scénario principal — Refuser¶

1. Le gestionnaire clique sur « Refuser » pour une réservation.
2. Un formulaire demande le motif de refus (obligatoire).
3. Il saisit le motif et confirme.
4. Le système passe le statut à rejected et enregistre le motif.
5. Le joueur reçoit une notification reservation_rejected avec le motif.

CU-RESERVATION-03 — Annuler une réservation¶

Scénario principal¶

1. L'acteur sélectionne la réservation à annuler.
2. Il confirme l'annulation.
3. Le système passe le statut à cancelled.

Scénario alternatif — Non autorisé¶

• Si l'utilisateur n'est ni le joueur concerné ni le propriétaire du club, le système retourne une erreur 403.

CU-RESERVATION-04 — Consulter l'historique des réservations¶

Scénario principal — Joueur¶

1. Le joueur accède à « Mes réservations » (GET /api/v1/reservations/my).
2. Il peut filtrer par statut : pending, accepted, rejected, cancelled.
3. Il peut annuler une réservation avec le statut pending.

Scénario principal — Gestionnaire¶

1. Le gestionnaire accède à la page Réservations de son club.
2. Le système liste toutes les réservations (GET /api/v1/clubs/{club}/reservations).
3. Il peut filtrer par statut et traiter les demandes en attente.