Journal des modifications

0.20.0.3 — 2026-07-20

Corrections

Responsable légal désormais réellement exigé pour un adhérent mineur sur le funnel public (art. 8 RGPD) : le libellé du formulaire annonçait un responsable légal « obligatoire » pour un mineur, mais rien ne le validait ni côté serveur ni côté client — une soumission sans tuteur passait. date_naissance passe de nullable à required (impossible de déterminer la minorité sans elle) et SubmitPublicRegistrationRequest::withValidator() bloque désormais toute soumission d'un membre de moins de 18 ans sans au moins un guardian renseigné.

0.19.0.0 — 2026-07-03

Ajouts

Lien de paiement en ligne pour panier offline impayé : depuis le détail panier, un bouton du panneau de relance génère un lien de paiement HelloAsso pour un panier initialement réglé hors ligne (chèque, virement, espèces) qui reste impayé — sans obliger l'adhérent à repasser par tout le formulaire. Guardé par token public valide, solde panier > 0 relu sous verrou, et HelloAsso configuré pour le tenant (le bouton est masqué sinon).
Verrou de checkout HelloAsso anti double-clic/double-onglet : Cache::lock par panier (30s, attente 5s) sérialise les checkouts concurrents sur le même jeu d'inscriptions ; le solde est relu sous verrou juste avant chaque appel HelloAsso, avec dégradation gracieuse (HelloAssoAlreadySettledException) si un règlement concurrent a déjà tout soldé. Les appels HTTP HelloAsso sont bornés à 10s pour ne jamais dépasser la durée du verrou.

Corrections

Le montant réclamé par la relance et le checkout HelloAsso se base désormais sur le solde du panier (VersementService::cartOutstandingCents), plus sur la ventilation par inscription — élimine les relances erronées après une re-ventilation des paiements à l'annulation.
Élimination de plusieurs N+1 (registration.payments, registration.balance) dans HelloAssoRelanceService et le flux de retry HelloAsso.
Exclusion des paiements HelloAsso fantômes de la relance panier : payableCartPayments() (et canSendManualRelance(), createOnlinePaymentLink()) retournent vide dès que le panier n'a plus de solde dû au niveau versement (VersementService::cartOutstandingCents), même si un Payment Pending/Rejected résiduel survit sur une inscription réglée hors ligne entre-temps ; garde sur destinataire absent ; resynchronisation de Payment.amount au moment du checkout.

0.18.3.0 — 2026-07-01

Ajouts

Refactoring MemberController::show() → CQRS read model (GetMemberDetailQuery) : la méthode show() passe de 263 lignes à ~12 lignes en déléguant à une query orchestratrice qui coordonne 7 assembleurs, chacun produisant un DTO final readonly typé. Les DTOs couvrent : PersonSectionData, MemberSectionData, UsagerSectionData, LegalGuardianData, PayeurSectionData, RegistrationSummaryData, MeetingActionData.
Limitation des inscriptions à 50 + hasMoreRegistrations : la query charge 51 inscriptions (LIMIT+1), n'en retourne que 50, et expose le flag hasMoreRegistrations pour signaler qu'il y en a davantage — sans pagination complète.
Migration index composite (tenant_id, responsible_user_id, due_date) sur meeting_actions : élimine le filesort sur ORDER BY due_date LIMIT 50 dans MeetingActionsAssembler.

Corrections

tenant_id ajouté aux selects contraints sur legalGuardians.person.adherent et payeurs.person.adherent (évite un null silencieux si $adherent->tenant_id est accédé ultérieurement).
toISOString() dans MeetingActionsAssembler (cohérence avec les autres assembleurs qui utilisaient déjà cette forme).
MemberDetailResponse::$member déclaré non-nullable (toujours valorisé par memberAssembler->assemble()).

Tests

Test 403 sur members.show sans permission (couverture manquante sur l'accès à la fiche membre).
Test LIMIT+1 (hasMoreRegistrations) avec 51 campagnes distinctes pour contourner la contrainte unique (member_id, campaign_id).
Test ModelNotFoundException sur un member_id inexistant.
Test isolation cross-tenant sur MeetingActionsAssembler : vérifie que le scope BelongsToTenant filtre les actions d'un autre tenant même si responsible_user_id est identique.
Test positif MeetingActionsAssembler avec fixture MeetingAction réelle (l'ancien test ne créait aucune action).

0.16.31.0 — 2026-06-25

Ajouts

Facture du panier en un coup d'œil + export PDF. La page « Détail du panier » affiche désormais une facture consolidée regroupant chaque inscrit, ses prestations et le total facturé (remises comprises). Un bouton « PDF » génère une facture agrégée du panier (une seule pièce pour l'ensemble des inscrits), sur le même modèle que les reçus existants.
Note interne au niveau du panier. Le gestionnaire peut saisir et modifier une note interne attachée au panier (paiement échelonné convenu, certificat reçu…), visible directement sur la page « Détail du panier ». La note n'est éditable que par un compte disposant de la mise à jour des adhérents ; un compte en lecture seule la consulte sans pouvoir la modifier. L'isolation entre associations est garantie (un panier d'une autre association renvoie une 404).

0.16.30.0 — 2026-06-24

Modifications

Gérer une inscription sans quitter le panier. Les actions par inscription (valider, demander la validation, refuser, annuler, ajouter / retirer / échanger un cours, prolonger l'acompte, envoyer le reçu) s'effectuent désormais directement dans l'accordéon de chaque inscrit sur la page « Détail du panier ». La fenêtre d'aperçu des montants (ajout / retrait / échange de cours) s'ouvre sur place, et chaque action rafraîchit les données sans changer de page. Le panier devient le poste de travail unique du gestionnaire.
Fiche inscription recentrée sur la consultation. La page d'une inscription conserve l'affichage détaillé (facture, notes, historiques) et la carte de relance, mais n'héberge plus les actions migrées ; le lien depuis le panier devient « Voir le détail ».
Aucune action visible pour un compte en lecture seule. Un utilisateur disposant uniquement de la consultation des adhérents ne reçoit aucun contrôle d'action sur le détail du panier (parité avec les contrôles côté serveur).

0.16.28.0 — 2026-06-23

Corrections

On reste sur le plan de paiement après une action. Enregistrer, encaisser ou rejeter un versement renvoie désormais vers la page « Plan de paiement » du panier, plus vers le détail du panier.
Barre de paiement lisible quand il n'y a aucun versement. La piste de la barre de progression reçoit une bordure : en thème sombre elle ne disparaît plus sur fond de carte, et le solde restant s'affiche désormais dans la légende.
Pas de reçu en double sur un double-clic. Marquer un versement reçu ou rejeté deux fois de suite (double-soumission) ne ré-envoie plus les e-mails de reçu ni ne réécrit l'historique : l'action est rendue idempotente sous verrou.

Modifications

Saisie d'un versement accessible depuis le détail du panier ET le plan de paiement. La fenêtre de saisie s'ouvre sur place (sans changer de page) ; seul l'enregistrement redirige vers le plan de paiement.
Le trésorier peut saisir et encaisser les versements (la saisie exige la permission de mise à jour des adhérents).

Sécurité

Isolation par association renforcée à la saisie d'un versement : un moyen de paiement personnalisé d'une autre association est refusé, et le paiement en ligne HelloAsso ne peut plus être choisi comme moyen de saisie manuelle.

0.16.24.0 — 2026-06-18

Ajouts

Écran d'accueil « Avant de commencer » au début du formulaire d'inscription public. Il explique en trois points comment se déroule l'inscription : une personne à la fois (ses activités puis ses coordonnées), d'autres ensuite si besoin (frère, sœur, proche), et un seul paiement à la fin pour toute la famille.

Modifications

Refonte de la barre de progression du formulaire d'inscription. Elle affiche désormais quatre étapes claires — Bienvenue, Adhérent(s), Payeur, Récap & paiement — avec une sous-étape Activités → Identité qui indique, pour chaque adhérent, où l'on en est, et rappelle qu'elle se répète pour chaque personne.
L'écran Coordonnées s'adresse à la bonne personne. Son titre reprend le prénom saisi (« Coordonnées · Nathan »), ou à défaut le rang de la personne (« 1ʳᵉ personne », « 2ᵉ personne »), pour qu'on sache toujours de qui on renseigne les informations.
Ajouter un adhérent supplémentaire mène directement à ses activités, exactement comme pour le premier adhérent. Le parcours d'ajout est uniforme : le prénom se renseigne à l'étape Coordonnées pour tout le monde.

0.16.22.0 — 2026-06-17

Modifications

Les e-mails du parcours d'inscription et de paiement adoptent une identité visuelle commune. Un châssis de marque partagé (en-tête au nom du club, mise en page, pied « Propulsé par Cohez.io ») est désormais appliqué aux mails du funnel — confirmation de panier, relance HelloAsso, paiement reçu, inscription validée, ajustement de panier. Chaque mail porte en pied son statut, sa référence de panier et sa date d'inscription, pour un repérage immédiat.
Le mail « Votre paiement a bien été reçu » est enrichi : il s'adresse nommément au payeur, récapitule le montant total, le montant déjà payé et le reste à régler, et précise le moyen de règlement utilisé.

Corrections

La relance d'acompte réaffiche la date limite de règlement. Lors de l'harmonisation des e-mails, l'échéance de l'acompte (« à régler avant le … ») avait disparu de la relance — pourtant le cœur du message. Elle est rétablie, par adhérent.
Le pied de l'e-mail d'inscription validée n'expose plus l'adresse du payeur. Le mail part toujours à l'adhérent ; le pied « Envoyé à » affichait par erreur l'adresse du payeur (libellé inexact et divulgation de données). Il affiche désormais l'adresse réelle du destinataire.
Les noms à apostrophe s'affichent en clair dans la version texte des e-mails (nom de club, de cours, de personne), au lieu d'une entité HTML illisible (').

Retraits

L'e-mail d'administration « Paiement reçu pour une inscription » est supprimé, jugé redondant. Le reçu envoyé au payeur reste inchangé.

0.16.21.0 — 2026-06-16

Modifications

L'export CSV des inscriptions s'enrichit de nouvelles colonnes : à la demande d'un club, l'export du back-office détaille désormais l'identité complète — nom, prénom et date de naissance de l'adhérent inscrit, nom et prénom du responsable légal (le contact principal, ou le plus ancien à défaut), ainsi que nom, prénom et e-mail du payeur. Les montants (total, payé, solde) sortent maintenant en euros avec la virgule décimale française (1234,50) au lieu des centimes, pour une lecture directe dans Excel — un trop-perçu reste correctement signé (-12,50). Saison, campagne, cours, libellé de statut, statut de paiement et date d'inscription restent présents. Les filtres de l'écran (saison, campagne, cours, statut, recherche) continuent de s'appliquer à l'export.

0.16.20.0 — 2026-06-16

Ajouts

Le payeur est prévenu par e-mail quand un cours est ajouté, retiré ou échangé : dès qu'un dirigeant modifie les activités d'une inscription depuis le back-office, le payeur du panier (ou l'adhérent à défaut) reçoit automatiquement un e-mail. Il indique clairement la modification faite (« Cours ajouté / retiré / modifié : … ») puis le récapitulatif à jour du panier : total, déjà réglé, reste à régler — ou un avoir en sa faveur si la modification crée un trop-perçu. Pour un panier en attente avec acompte, le bloc acompte (acompte à régler, solde ultérieur) est affiché. L'e-mail porte l'identité du club (expéditeur, contact) et reprend la présentation de l'e-mail de confirmation. Une inscription annulée du même panier n'apparaît pas dans le récapitulatif. Chaque modification déclenche son propre e-mail. Techniquement, l'échange émet désormais un événement applicatif dédié RegistrationCourseSwapped (l'ajout et le retrait réutilisent les événements existants) ; l'envoi passe par des listeners en file d'attente (3 tentatives) qui n'interrompent jamais la modification en cas d'échec d'envoi.