Journal des modifications

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.

0.16.19.0 — 2026-06-15

Ajouts

Ajouter ou retirer un cours sur une inscription existante (back-office) : depuis la fiche d'une inscription non terminale (brouillon, en attente de validation ou validée), on peut maintenant ajouter une activité ou en retirer une, sans repasser par un échange complet. Un aperçu affiche le nouveau montant dû et le solde projeté avant de confirmer, et chaque opération demande un motif tracé dans l'historique de l'inscription. Le montant dû est recalculé automatiquement : un ajout fait réapparaître un solde, un retrait peut créer un trop-perçu (l'acompte dû est alors ramené au nouveau total). Retirer le dernier cours laisse une inscription à 0 €. Pour une inscription déjà facturée, une nouvelle version de la facture est générée. Les places restantes du cours visé sont contrôlées (un cours complet est refusé) et un ajout en double simultané est bloqué. Techniquement, l'ajout et le retrait émettent désormais des événements applicatifs (RegistrationCourseAdded, RegistrationCourseRemoved) après commit — socle de la future traçabilité d'audit ; l'échange n'en émet pas.

0.16.18.0 — 2026-06-15

Ajouts

Commande registrations:resend-cart-confirmation : outil de rattrapage pour renvoyer l'e-mail récapitulatif de panier aux payeurs d'inscriptions enregistrées avant le déploiement de cette fonctionnalité, qui ne l'ont donc jamais reçu. Ciblage par tenant et par fenêtre de dates, dry-run par défaut (envoi réel via --send), exclusion automatique des inscriptions ayant déjà reçu un e-mail lié à leur paiement.

Corrections

E-mail de confirmation envoyé pour toute inscription en ligne : après une inscription via le formulaire public, le payeur reçoit désormais systématiquement un e-mail récapitulatif, quel que soit le moyen de paiement (HelloAsso, chèque, virement, espèces…) et dès que l'inscription est enregistrée — sans attendre la validation. Auparavant, seules les inscriptions réglées hors ligne déclenchaient un accusé : les paiements HelloAsso n'en recevaient aucun.

Modifications

Un seul e-mail récapitulatif par panier, adressé au payeur : pour une inscription groupée (plusieurs adhérents en une soumission), le payeur reçoit un unique e-mail listant tous les adhérents et le détail des montants, au lieu d'un message par adhérent.
E-mail de confirmation refondu aux couleurs du club : l'e-mail porte désormais l'identité de l'association (nom du club en en-tête et comme expéditeur, bloc contact, mention « Propulsé par Cohez.io » discrète en pied de page) au lieu de l'image Cohéz.io. Récapitulatif par adhérent avec sous-total par personne quand le panier en compte plusieurs et total global mis en avant, action de paiement adaptée au moyen choisi (chèque, virement, espèces, paiement en ligne), référence et date d'inscription. Gabarit HTML compatible messageries (mise en page en tableaux, styles en ligne, largeur 600 px, mode sombre) accompagné d'une version texte.

0.16.17.0 — 2026-06-13

Ajouts

Moteur de périodes d'adhésion (fondation) : chaque adhésion devient une période datée (début/fin), seule source de vérité du statut « adhérent / expiré » — désormais toujours dérivé des dates, jamais saisi à la main. À la validation d'une inscription, la période d'adhésion correspondante est créée automatiquement selon les réglages du tenant (année glissante d'un an, ou période fixe type saison sportive septembre→août). Une adhésion à vie n'a pas de date de fin. Cette version pose la table et l'automatisation côté serveur ; les écrans de consultation suivront.
Commande de reprise de l'existant php artisan memberships:backfill : reconstruit les périodes d'adhésion d'un club déjà en service à partir des dates d'expiration saisies ET de l'historique des inscriptions validées, avec un mode --dry-run pour vérifier avant d'écrire. Refuse de s'exécuter tant que le type de renouvellement n'est pas configuré, pour ne pas figer un calcul par défaut erroné.

Modifications

Réglages d'adhésion : dates de renouvellement impossibles refusées : le formulaire de l'association rejette désormais un jour/mois de début de période qui n'existe pas (31 février, 31 avril…), tout en acceptant le 29 février (ramené au dernier jour du mois les années non bissextiles lors du calcul).

0.16.16.0 — 2026-06-12

Corrections

Liste des inscrits d'un cours cohérente avec le compteur de places : une inscription en brouillon occupe une place (comptée dans le badge « X/Y ») mais n'apparaissait pas dans la liste des inscrits ni dans l'export CSV du cours, créant une place « fantôme ». La liste et l'export incluent désormais les brouillons, alignés sur le compteur. Source de vérité unique pour tous les écrans : seuls les statuts terminaux (annulée, refusée, abandonnée) libèrent une place.

Ajouts

Filtre « Brouillon » dans la liste des inscrits de la fiche cours, pour isoler les inscriptions en cours de validation.

0.16.15.0 — 2026-06-12

Ajouts

Export CSV de la liste des inscriptions : un bouton « Exporter CSV » sur la page des inscriptions télécharge exactement le jeu filtré à l'écran (mêmes saison, campagne, cours, statut, recherche), y compris en mode « Toutes les saisons ». Pensé pour la transmission au trésorier / à la comptabilité : colonnes financières (montant dû, total payé, solde) et de réconciliation (saison, campagne, cours), sans donnée d'e-mail.
Permission dédiée « Exporter les inscriptions » : l'export est réservé aux rôles qui en disposent (administrateur et trésorier par défaut), distincte de la simple consultation de la liste. À ré-attribuer aux rôles concernés après déploiement (re-seed des permissions).

Modifications

Fichier CSV adapté au tableur français : séparateur point-virgule et marque d'ordre des octets (BOM) pour une ouverture propre dans Excel/LibreOffice en français, avec accents corrects. Les montants sont exportés en centimes entiers pour une addition fiable quelle que soit la configuration régionale.

Sécurité

Protection anti-injection de formule mutualisée dans un trait partagé : les valeurs texte commençant par =, +, -, @ (etc.) sont neutralisées dans tous les exports CSV (inscriptions et membres d'un cours). Les colonnes numériques ne sont jamais altérées (un solde négatif reste un nombre).

0.16.14.0 — 2026-06-11

Modifications

Mise à jour d'un membre désormais atomique : la modification d'une fiche membre (identité, adresse, type, statut, renouvellement, consentements) est enregistrée en une seule opération. En cas d'erreur en cours de route, plus aucune écriture partielle — soit tout est sauvegardé, soit rien.

Corrections

Étanchéité entre associations renforcée : tenter d'accéder ou de modifier la fiche d'un membre appartenant à une autre association renvoie désormais une page « introuvable » (404) au lieu de révéler son existence (403). Le filtrage par association s'applique avant la résolution de la fiche.

0.16.13.0 — 2026-06-11

Ajouts

Gestion des inscriptions — filtre par saison, campagne et cours : la liste s'ouvre désormais sur la saison active et se filtre par saison (axe principal), puis affine par campagne et par cours. Le sélecteur « Toutes les saisons » lève le filtre. Campagne et cours se limitent automatiquement à la saison choisie.
Bandeau de remplissage du cours : quand un cours est sélectionné, un bandeau indique le nombre d'inscrits actifs, la capacité, les places restantes et signale « Complet » dès que la capacité est atteinte. Les inscriptions annulées sont exclues du compteur.

Modifications

Mise en page des filtres d'inscriptions réorganisée sur trois niveaux (contexte saison/campagne/cours, puis recherche/statut/tri, puis réinitialisation) avec un séparateur visuel entre les filtres et la liste.

Corrections

Le filtre statut de la liste d'inscriptions est désormais validé (valeurs hors énumération rejetées).
Le sélecteur de saisons reste synchronisé avec les données serveur lors des navigations conservant l'état.

Ajouts

Relancer un paiement depuis la fiche d'inscription. Un nouveau panneau « Relancer le paiement » apparaît sur la fiche d'une inscription dont le paiement reste dû, pour l'équipe disposant du droit de gestion des membres. Pour un règlement HelloAsso, la relance renvoie un e-mail contenant un lien de paiement fiable (ancré sur le panier) ; le destinataire affiché avant l'envoi est exactement celui qui recevra le mail. Une relance récente (moins de 24 h) est signalée pour éviter les envois en rafale, et la date de la dernière relance est rappelée.
Rappeler par e-mail les impayés réglés hors ligne. Pour une inscription non soldée dont le règlement attendu est un chèque, un virement, des espèces ou un moyen personnalisé (donc sans paiement HelloAsso), l'équipe peut envoyer un rappel par e-mail. Le rappel indique le montant restant dû, le moyen de paiement prévu et la date limite lorsqu'elle existe — sans aucun lien de paiement, puisque l'association n'encaisse pas en ligne dans ce cas.

Modifications

Les e-mails partent au nom de l'association. Les e-mails adressés aux adhérents et payeurs (confirmation, reçu, relance, validation, rappel…) affichent désormais le nom de l'association comme nom d'expéditeur, au lieu d'un nom générique. L'adresse d'envoi technique reste inchangée (SPF/DKIM préservés).

Technique

Nouvelle colonne payments.manual_relance_sent_at, distincte de helloasso_relance_sent_at : une relance manuelle n'est plus ré-armée par la synchronisation automatique, et la relance automatique (cron) exclut les paiements déjà relancés à la main. Une nouvelle tentative de paiement du payeur ré-arme la relance manuelle pour ne pas exclure le panier à vie.
Trait WithTenantSender appliqué à l'ensemble des mailables tenant (expéditeur = nom du tenant, repli sur le nom global si absent).

0.16.11.0 — 2026-06-09

Corrections

Les paiements HelloAsso déclenchent enfin un vrai reçu. Quand un paiement HelloAsso était confirmé (retour de paiement, webhook ou synchronisation), l'application marquait le paiement comme reçu mais n'envoyait aucun reçu au payeur ni aucune notification à l'association — contrairement à un paiement enregistré à la main. Pire, l'e-mail de confirmation envoyé après paiement affichait « Statut : En attente », ce qui contredisait le paiement qui venait d'aboutir. Désormais, comme pour le flux manuel, chaque paiement HelloAsso confirmé envoie le reçu (avec le solde restant le cas échéant) au payeur et notifie l'association.
L'adhérent reste informé même quand un tiers paie son acompte. Sur un acompte réglé via HelloAsso par un payeur distinct (parent, tiers payeur), l'adhérent ne recevait plus aucune notification sur sa propre inscription. Il reçoit maintenant une copie du reçu d'acompte. Sur un paiement intégral, l'adhérent est déjà prévenu par l'e-mail de validation, sans envoi en double.
L'e-mail de confirmation d'inscription affiche le bon statut de paiement. Le statut (« En attente », « Acompte reçu, solde en attente », « Payé ») est maintenant calculé selon l'état réel de l'inscription, et le bloc « Acompte requis » ne s'affiche plus que pour une inscription encore en brouillon.

Retraits

Bouton « Voir mon inscription » retiré des e-mails adressés aux adhérents. Il pointait vers une page du back-office accessible uniquement à l'équipe : l'adhérent tombait sur une page de connexion. Les liens légitimes vers le règlement HelloAsso (relances) sont conservés.