Journal des modifications

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.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.10.0 — 2026-06-08

Corrections

Les liens « Finalisez votre paiement » des e-mails de relance HelloAsso fonctionnent à nouveau. Le lien encodait la référence du checkout HelloAsso, qui change à chaque nouvelle tentative de paiement : dès qu'un nouveau checkout était généré (premier clic du payeur, re-soumission), l'ancienne référence devenait orpheline et le payeur tombait sur la page « Le paiement n'a pas pu être finalisé », sans aucun recours. Le lien s'appuie désormais sur l'identité stable du panier (l'ensemble des inscriptions d'une même soumission), de sorte qu'il reste valide quel que soit le nombre de tentatives.
Plus de page d'erreur muette au clic sur un lien de relance. Selon l'état réel, le payeur voit maintenant un message clair : « Paiement déjà réglé », « Cette inscription n'est plus active », « Lien expiré » ou une vraie erreur technique avec possibilité de recommencer. Un échec technique de création du checkout ne « brûle » plus la relance : l'inscription reste éligible à un rappel ultérieur.

Ajouts

Notion de panier (cart_id) sur les inscriptions. Les inscriptions issues d'une même soumission multi-membres partagent désormais un identifiant de panier stable, posé à la création et jamais réécrit. Il sert de socle au lien de relance fiable et prépare les évolutions à venir (récapitulatif du solde, gestion de commande). Les inscriptions existantes ont été rattachées à un panier par migration (regroupement par payeur et date pour les paiements tiers, panier individuel sinon).

Modifications

Traçabilité renforcée du cycle de relance et de paiement HelloAsso. Chaque étape (clic du lien, résolution du panier, décision d'état, re-création du checkout, succès ou échec) est désormais journalisée avec un contexte structuré (préfixe helloasso.*), pour diagnostiquer rapidement en production.

0.16.8.0 — 2026-06-05

Modifications

Paiement manuel : avancement automatique d'une inscription en brouillon : lorsque l'équipe marque un paiement comme reçu sur une inscription en brouillon, celle-ci avance désormais automatiquement, à l'image du flux HelloAsso. Elle passe en Validée si le paiement solde le montant dû (ce qui génère la facture et l'email de validation), ou en En attente de validation s'il s'agit d'un paiement partiel. Auparavant l'inscription restait bloquée en brouillon malgré l'encaissement (place de cours retenue, dossier invisible des relances). Les inscriptions déjà validées, en attente ou annulées ne sont pas affectées : leur statut reste administratif.

Corrections

Plus d'abandon d'une réservation dont le chèque a été déposé mais pas encore encaissé : le cron d'abandon (registrations:abandon-expired-deposits) ne libère plus une réservation expirée si elle porte un engagement de paiement — un paiement déjà reçu, ou un paiement manuel (chèque, virement, espèces…) saisi par le back-office et encore en attente d'encaissement. Auparavant, un chèque déposé puis enregistré mais pas encore marqué « reçu » laissait la réservation en brouillon, qu'un délai dépassé pouvait faire abandonner à tort (place libérée alors que le chèque était en main). Le critère « saisie back-office » (paiement avec un auteur, created_by) exclut les paiements Pending créés par le formulaire public à la soumission : une inscription publique jamais réglée doit, elle, être libérée à l'échéance. Les tunnels HelloAsso abandonnés (paiement HelloAsso resté Pending) et les chèques rejetés restent également abandonnables.

Technique

PaymentController::markAsReceived enveloppe la mise à jour du paiement, la relecture verrouillée de l'inscription (lockForUpdate) et la transition de statut dans une transaction unique ; l'événement RegistrationValidated est dispatché après commit pour que le listener de facture (CreateRegistrationInvoiceListener, idempotent) lise l'état persisté. La transition ne s'applique qu'aux inscriptions en Draft (re-test du statut sous verrou → pas de double-transition concurrente). Couverture étendue : transition pleine (Validated) / partielle (PendingValidation), statuts non-brouillon inchangés, et PaymentObserverTest mis à jour pour le nouveau contrat.
AbandonExpiredDepositsCommand : le garde « ne pas abandonner si payé » devient un garde « engagement » — freshPayments->contains(Received || (Pending && method !== HelloAsso && created_by !== null)). Discriminants : method (chèque en attente d'encaissement vs checkout HelloAsso abandonné) et created_by (saisie back-office vs Payment Pending créé par le formulaire public, jamais réglé). 5 tests ajoutés (chèque manuel back-office protège, virement manuel back-office protège, Pending public abandonné, HelloAsso Pending abandonné, chèque Rejected abandonné).

0.16.3.0 — 2026-06-03

Ajouts

Traçabilité des emails de relance : chaque email de relance envoyé pour un dossier d'inscription est désormais enregistré (paiement HelloAsso rejeté, paiement abandonné, ou acompte expirant), avec le destinataire, la raison, la référence de checkout et la date d'envoi.
Historique des relances sur la vue dossier : une carte « Relances envoyées » liste les relances du dossier, avec un badge coloré par type (rejeté, abandonné, acompte) et l'horodatage de chaque envoi.

Technique

Nouvelle table registration_relance_emails (une ligne par email) et table pivot vers les dossiers concernés (un email groupé peut couvrir plusieurs dossiers).
L'enregistrement des traces est centralisé dans un recorder best-effort (RegistrationRelanceEmail::record()), branché sur le goulot d'envoi HelloAsso et sur la relance d'acompte. Une défaillance de la trace n'interrompt jamais l'envoi du mail.

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.0.0 — 2026-05-20

Ajouts

Règle d'acompte par campagne : les admins peuvent configurer sur chaque campagne une règle d'acompte (% global ou % / montant fixe par rubrique) avec une date-limite d'expiration et les méthodes de paiement déclenchantes.
Settlement method : le mode de règlement du solde (HelloAsso, virement, chèque…) est distinct des méthodes déclenchantes. Permet le flux « paiement partiel HelloAsso + solde hors-ligne ».
Checkout HelloAsso dépôt : si la méthode du payeur déclenche la règle et que le settlement est HelloAsso, un checkout HA est créé pour le montant du dépôt uniquement (pas le total). payment.notes contient checkout_type: deposit pour identifier le retour.
Statut PendingValidation : les inscriptions offline avec règle d'acompte passent immédiatement en PendingValidation (en attente de confirmation de paiement par l'admin).
Email de relance dépôt : si le retour HelloAsso arrive sans paiement confirmé, un email de relance (DepositRelanceMail) est envoyé une seule fois (guard deposit_relance_sent_at atomique via lockForUpdate).
Prolongation du délai : l'admin peut prolonger la date-limite d'acompte d'une inscription depuis la fiche inscription. L'adhérent reçoit un email DepositDeadlineExtendedMail.
Notification admin paiement reçu : à chaque marquage « paiement reçu », l'admin reçoit un email AdminPaymentReceivedMail si le tenant a un contact_email.
Abandon automatique des acomptes expirés : la commande cron abandonne désormais aussi les inscriptions en attente de validation (PendingValidation) dont le délai est dépassé, en plus des brouillons — sans toucher aux inscriptions dont le dépôt a déjà été reçu.
Texte explicatif configurable : l'admin peut saisir un message libre (explanation_text) visible dans l'email de confirmation et sur la page de succès publique, pour indiquer au payeur comment régler le solde (ex. coordonnées virement, adresse pour chèque).

Pour les contributeurs

CampaignDepositRule : nouveaux champs settlement_method (string nullable), explanation_text (text nullable). global_percentage devient nullable. Nouveau config_type = rubrique_rules avec colonne rubrique_rules (JSONB).
registrations : nouveau champ deposit_relance_sent_at (timestamp nullable).
DepositCalculatorService : gère les deux config_type. rubrique_rules : calcul par rubrique avec modes percentage et fixed_per_item.
Webhook HelloAssoWebhookController : checkout_type lu depuis payment.notes (stocké server-side) et non depuis le body du webhook (non fiable pour les transitions asynchrones).
Validation rubrique_rules.*.rubrique_id : scopée tenant + campagne pour éviter l'injection cross-campagne qui produirait un dépôt €0.