Journal des modifications

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.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.

0.16.9.0 — 2026-06-05

Corrections

Le formulaire public ne crée plus de « paiement en attente » fantôme pour les règlements hors ligne. Quand un adhérent s'inscrivait en choisissant un règlement par chèque, virement, espèces ou moyen personnalisé, l'application enregistrait aussitôt un paiement « en attente » alors qu'aucun argent n'avait circulé — le choix du moyen n'est qu'une intention, pas un paiement. Désormais seul HelloAsso génère un paiement à la soumission (support du tunnel de règlement). Pour les autres moyens, le choix de l'adhérent est conservé comme information sur l'inscription et affiché tel quel (email de confirmation, fiche back-office) ; l'équipe enregistre le paiement réel à la réception effective des fonds.

Technique

PublicRegistrationService ne crée un Payment (Pending) que lorsque le moyen résolu est HelloAsso (cas A acompte HA + paiement intégral HA). Les moyens hors ligne (chèque, virement, espèces, custom) ne matérialisent aucun paiement. Le gate porte sur la variable résolue (en cas A elle est forcée à HelloAsso pour le checkout, même si l'adhérent a coché chèque).
Nouvelles colonnes registrations.intended_payment_method (enum) + intended_custom_payment_method_id (FK tenant_payment_methods, nullOnDelete). Aucun backfill : les inscriptions antérieures restent à null (libellé « — »).
Registration::intendedPaymentMethodLabel() centralise la résolution du libellé (custom via relation, enum standard, null) ; l'email de confirmation et la fiche back-office la consomment (plus de lecture depuis le paiement supprimé).
Tests : flux offline = 0 paiement + intention stockée, HelloAsso = 1 paiement, cas A/B/C, méthode custom, rendu réel de l'email, libellé back-office, et résolution du libellé (null/standard/HelloAsso/custom/custom supprimé).

0.16.6.0 — 2026-06-04

Ajouts

Indicateur « Trop-perçu » sur une inscription : lorsqu'un adhérent paie plus que le montant dû (par exemple un chèque qui dépasse le solde restant), l'écran de l'inscription affiche désormais clairement l'état « Trop-perçu » — une carte ambre indiquant le montant payé en trop (montant positif) et un badge « Trop-perçu » en en-tête. Auparavant, ce cas se traduisait par un « Solde : -10,00 € » négatif et déroutant. Le marquage d'un paiement comme « Reçu » n'a jamais été bloqué par un trop-perçu ; seul l'affichage manquait.

0.16.4.0 — 2026-06-04

Corrections

Cours affiché « complet » alors qu'il restait des places : un cours pouvait apparaître complet sur le formulaire d'inscription public alors que le compte admin affichait encore des places disponibles. Deux causes : (1) le formulaire et l'admin ne comptaient pas le même ensemble de statuts (les inscriptions Draft comptaient côté formulaire mais pas côté admin) ; (2) des inscriptions Draft issues d'un checkout HelloAsso abandonné (paiement jamais finalisé) restaient bloquées indéfiniment et occupaient une place à vie. Le comptage de capacité est désormais unifié sur tous les écrans (formulaire public, Cours, Campagnes, Réglages > Cours) et les réservations en attente non finalisées sont automatiquement libérées après un délai.

Ajouts

Délai d'expiration des réservations en attente : toute réservation non finalisée (Draft) reçoit désormais une date limite. Passé ce délai sans paiement, elle est automatiquement annulée et sa place libérée. Le délai par défaut est de 7 jours (configurable via REGISTRATION_DRAFT_TTL_DAYS).
Surcharge du délai par campagne : chaque campagne peut définir son propre délai d'expiration des réservations en attente, via un champ dédié dans le formulaire de campagne (laisser vide pour utiliser le défaut global).
Édition de campagne accessible : un bouton « Modifier » permet désormais d'éditer une campagne existante depuis sa page (la page d'édition existait mais n'était reliée à aucun lien).

Technique

Nouvelle colonne registrations.draft_expires_at (date limite générique de réservation) et campaigns.draft_ttl_days (surcharge par campagne). La date limite d'acompte (deposit_expires_at) reste prioritaire quand elle existe, avec repli sur draft_expires_at.
Les échéances de réservation et d'acompte sont désormais calées sur la fin de journée (endOfDay()) à la création comme au backfill, cohérent avec un cron quotidien : l'expiration correspond à la date affichée à l'adhérent et lui laisse sa dernière journée entière.
Le job registrations:abandon-expired-deposits annule désormais tout Draft expiré (plus seulement les acomptes) ; il n'expire jamais un PendingValidation via draft_expires_at (un paiement enregistré tient la place). Garde-fou : aucune réservation ayant déjà reçu un paiement n'est annulée (total_paid non nul). Il est désormais planifié une fois par jour à 07:00, après helloasso:sync-pending-payments (06:00) au lieu de toutes les heures : la synchronisation réconcilie d'abord les paiements HelloAsso réellement reçus, évitant d'abandonner par erreur une inscription payée mais pas encore synchronisée (sync ignore les statuts terminaux).
Comptage de capacité centralisé sur RegistrationStatus::terminalStatuses() (exclut Cancelled/Refused/Abandoned, compte les Draft) avec COUNT(DISTINCT), partagé par le modèle Course, CourseController, Settings/CourseController et CampaignController. Les listes de membres (roster, export CSV) continuent d'exclure les Draft.
Nouvelle commande ponctuelle registrations:backfill-draft-deadlines (avec --dry-run) pour poser une échéance sur les Draft existants créés avant ce correctif. À lancer une fois après déploiement.
Le balayage d'abandon parcourt les inscriptions avec chunkById (et non each/offset) : comme il fait sortir chaque ligne du jeu de résultats, une pagination par offset sauterait des lignes au-delà de la première page (places retenues à vie) — chunkById les traite toutes.
Garde de fraîcheur : si au moins un tenant utilise HelloAsso, l'abandon ne tourne que si helloasso:sync-pending-payments a réussi dans les 6 dernières heures (heartbeat en cache). Sinon il s'abstient (log d'avertissement) pour ne pas abandonner une inscription payée mais pas encore réconciliée si le sync échoue.

0.16.0.0 — 2026-06-02

Ajouts

Recherche par adhérent ou payeur sur la liste des inscriptions : tapez un nom, prénom ou email pour filtrer instantanément. La recherche est insensible à la casse et couvre à la fois le membre et le payeur (le cas échéant).
Tri par date d'arrivée : un bouton bascule permet d'afficher les inscriptions du plus récent au plus ancien ou inversement.
Bouton « Réinitialiser les filtres » : apparaît dès qu'un filtre actif est détecté (campagne, statut, recherche ou tri non-défaut) ; un clic remet tout à zéro en une seule action.
États vides distincts : une icône et un message différenciés pour « aucune inscription » (liste vide) et « aucun résultat » (filtres actifs sans correspondance).

Corrections

Les liens de pagination conservent désormais tous les filtres actifs (campagne, statut, recherche, tri) lorsqu'on navigue entre les pages.

0.15.0.0 — 2026-06-02

Ajouts

Relance paiement HelloAsso : les payeurs dont le paiement HelloAsso est rejeté par la banque ou abandonné depuis plus de 2h reçoivent automatiquement un email de relance avec le récapitulatif de leur inscription et un lien sécurisé pour relancer le paiement (URL signée, valable 7 jours).
Route de retry HelloAsso (/register/{token}/helloasso/retry) : crée un nouveau checkout HelloAsso à la volée sans effacer l'inscription existante. Protégée par URL signée temporaire pour prévenir les accès non autorisés.
Statuts de paiement HelloAsso dans l'interface admin : les inscriptions affichent désormais "HelloAsso en attente" (badge orange) et "Paiement refusé" (badge rouge) pour distinguer visuellement les checkouts en cours des paiements rejetés par la banque.
Détail complet du panier dans l'email de relance : l'email de relance affiche désormais chaque adhérent inscrit avec le détail par rubrique, les réductions appliquées, le montant de l'acompte le cas échéant et sa date d'expiration.
Planification nocturne : helloasso:sync-pending-payments s'exécute automatiquement chaque nuit à 06:00 (Europe/Paris) pour rattraper les paiements en attente non notifiés par webhook.
Annulation automatique : lorsqu'une inscription passe en statut Abandonné ou Annulé, les paiements HelloAsso Pending/Rejected associés sont automatiquement annulés pour éviter les relances intempestives.

Modifications

La commande helloasso:sync-pending-payments envoie maintenant un email de relance lors de la détection d'un paiement rejeté ou d'un checkout abandonné (>2h), avec idempotence garantie par le flag helloasso_relance_sent_at sur les paiements.
Le webhook HelloAsso (Refused) envoie immédiatement un email de relance au payeur après avoir marqué le paiement comme rejeté.
Les inscriptions en statut terminal (Refusé, Annulé, Abandonné) sont exclues des relances automatiques.
La logique d'envoi de l'email de relance est désormais centralisée dans HelloAssoRelanceService pour éviter la duplication entre le webhook et la commande de synchronisation.

Corrections

Correction d'un bug de double-email : après un retry, le délai de grâce de 2h pour la relance des abandonnés repart maintenant correctement de la date de modification du paiement (et non de sa création initiale).
json_decode sur les notes de paiement corrompues retourne désormais [] au lieu de null, évitant un recalcul incorrect du montant lors d'un retry de dépôt.
La route de retry ne supprime plus les inscriptions existantes en cas d'échec de l'API HelloAsso (contrairement au flux initial d'inscription).
L'URL de relance (bouton "Finaliser mon paiement") utilisait la racine de l'application au lieu du sous-domaine tenant, provoquant une erreur 404 à la réception de l'email.
Ajout du statut Cancelled dans l'enum PaymentStatus (manquant depuis la création, causait une erreur 500 lors de l'annulation d'inscription).

0.13.6.0 — 2026-05-27

Corrections

Cohérence UX du wizard d'inscription public (8 correctifs) :
- Libellés de boutons clarifiés : « Valider l'adhérent → » devient « Continuer — Informations personnelles → » (étape activités) ; le bouton retour de l'étape identité devient « ← Précédent » selon le contexte.
- Astérisques obligatoires supprimés des champs facultatifs : Nom, Email, Date de naissance, Adresse, Code postal, Ville n'affichaient plus de * rouge trompeur — seul Prénom (champ requis en base) conserve la marque.
- Navigation « Modifier l'identité » depuis la récapitulatif des adhérents : le bouton unique « Modifier » est remplacé par deux boutons distincts « Modifier les activités » et « Modifier l'identité ». Le bouton ← Précédent dans l'étape identité renvoie directement à la transition quand on arrive depuis ce chemin.
- Libellés de relation tuteur traduits : mere, pere, beau_pere… s'affichent désormais en français (Mère, Père, Beau-père…) dans la liste des options payeur.
- Email payeur tiers affiché dans le récap : la section récapitulatif affichait — pour un payeur tuteur (branche guardian non gérée). L'email est maintenant correctement récupéré depuis members[i].guardians[j].email.
- Validation email en temps réel (payeur tiers) : une erreur s'affiche au blur si le format n'est pas valide, et le bouton « Continuer » reste désactivé tant que l'email est absent ou invalide.
- Erreur email réinitialisée au changement de type payeur : l'erreur locale payerEmailLocalError est effacée lorsqu'on change de type de payeur, évitant un message fantôme à la re-sélection de « Tiers ».
- Compteur d'adhérents dans le Stepper : lors d'une inscription multi-adhérents, la bulle de progression affiche « N/Total · Adhérent » (ex. « 2/3 · Adhérent ») au lieu d'un label générique.
Correctif navigation flags : onIdentityPrev() réinitialisait correctement editingIdentityFromTransition mais laissait editingMemberFromTransition actif lors du retour vers l'étape activités, causant un saut involontaire vers la transition à la prochaine navigation arrière.

Interne

TODO ajouté : liens cliquables vers les statuts / règlement intérieur dans StepIdentite.vue (dépend du stockage d'URL en DB).