Journal des modifications

0.13.3.0 — 2026-05-25

Modifications

Récapitulatif d'inscription publique plus clair : la bande des adhérents affiche désormais « 1 activité · 1 adhésion » au lieu d'un compte global trompeur (« 2 activités » alors qu'il s'agissait d'une activité et d'une cotisation). La distinction repose sur un nouveau flag isActivity exposé par le backend pour chaque proposition.
Date d'échéance d'acompte au format jj/mm/aaaa partout : le récap, la page de succès et le mail de confirmation utilisent le même format court (01/06/2026) au lieu de mélanger « 1 juin 2026 » et 2026-06-01. La date est formatée côté serveur — plus de parsing JavaScript susceptible de décaler l'affichage d'un jour pour les utilisateurs hors métropole (DOM-TOM, fuseaux à l'ouest de UTC).
Page de succès enrichie pour les dépôts offline : affiche désormais l'acompte à régler, le reste à régler ensuite, et le total de l'inscription. Avant on ne voyait que la date limite et l'acompte.

Corrections

Message d'acompte reformulé : « Le paiement de l'acompte est nécessaire pour réserver la place dans un cours. » remplace « Réservez votre place avec un acompte » — clarifie que c'est obligatoire, pas optionnel.

Interne

Extrait formatCentimesOrNull(int): ?string dans PublicRegistrationController pour dédupliquer le pattern Money/EUR/garde->0 répété 3× dans store().
Test e2e Pest qui vérifie le calcul effectif total/dépôt/reste après POST sur store() avec un dépôt offline de 30%.

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.

0.12.0.0 — 2026-05-16

Ajouts

Facture d'inscription : à la validation d'une inscription, un snapshot immuable est automatiquement créé. Il capture les lignes de propositions (nom, quantité, montant unitaire, sous-total), le total facturé, les remises appliquées et le contexte (membre, campagne, saison, payeur) figé au moment de la validation. La fiche inscription affiche désormais un encart « Facture d'inscription » avec toutes ces informations.
member_index sur les inscriptions : indice de position du membre dans le foyer (0 = 1er, 1 = 2ème…), utilisé pour calculer les remises famille dans le snapshot.

Pour les contributeurs

Table registration_invoices : stocke le snapshot JSONB de chaque inscription validée. Contrainte unique sur (registration_id) garantissant l'idempotence. Les colonnes snapshotted_at et snapshotted_by permettent la traçabilité.
RegistrationInvoice (Eloquent) : modèle avec cast JSONB automatique, relations vers Registration et Tenant.
CreateRegistrationInvoiceListener : écoute l'événement RegistrationValidated. Résilient : si la création du snapshot échoue (indisponibilité DB…), la validation de l'inscription réussit quand même (erreur loguée sans propager l'exception).
total_discount dérivé arithmétiquement : sum(lignes.subtotal) - adjustment_amount - amount_due, toujours cohérent sans re-calcul des règles de tarification.
RegistrationStatus simplifié : les cas Paid et PaidPartial sont supprimés. Le statut de paiement est désormais dérivé à la demande via l'accessor payment_status. PaymentObserver réduit à des no-ops. Migration de backfill incluse (paid/paid_partial → validated).

0.11.0.0 — 2026-05-15

Ajouts

Moyens de paiement configurables par association : chaque association peut désormais activer/désactiver et personnaliser ses moyens de paiement depuis Paramètres → Moyens de paiement. Les méthodes standard (HelloAsso, Chèque, Virement, Espèces, Carte bancaire, Autre) peuvent être désactivées individuellement. Des méthodes personnalisées (libellé libre) peuvent être créées, éditées et supprimées. HelloAsso est automatiquement masqué si l'association n'a pas configuré ses identifiants API.
Carte bancaire ajoutée comme méthode standard par défaut pour tous les tenants existants.

Modifications

PaymentMethod enum : les cas VacationVoucher et PassSport sont retirés de l'enum (chèques vacances / Pass Sport — spécifiques France). Les associations qui les utilisaient doivent les recréer comme méthodes personnalisées. Les paiements existants avec ces méthodes sont automatiquement reclassés en other via migration.
Formulaire d'inscription public : les méthodes de paiement affichées sont désormais filtrées par la configuration du tenant (seules les méthodes activées apparaissent). CreditCard (Carte bancaire) s'affiche correctement.

Pour les contributeurs

Table tenant_payment_methods : nouvelle table relationnelle stockant la configuration de chaque moyen de paiement par tenant, avec index unique partiel (PostgreSQL) garantissant l'unicité des méthodes standard par tenant.
TenantPaymentMethod (Eloquent) : nouveau modèle gérant les méthodes standard et personnalisées, avec la relation inverse vers Payment.
Page Filament PaymentMethodResource : interface d'administration self-service pour la gestion des moyens de paiement, avec formulaire inline et actions de réordonnancement.
Migration de sécurité : les lignes payments.method contenant vacation_voucher ou pass_sport sont reclassées en other avant la suppression des cas de l'enum, évitant toute ValueError de PaymentMethod::from() au chargement.
Vérification is_enabled dans le store public : la résolution d'une méthode personnalisée dans PublicRegistrationController::store() vérifie désormais que la méthode est bien activée (is_enabled = true).

0.6.0.0 — 2026-05-08

Ajouts

Inscription publique multi-adhérents : un même formulaire permet désormais d'inscrire plusieurs membres d'une famille en une seule opération. Un wizard en 5 étapes guide le responsable : identité de chaque adhérent, choix des activités, résumé intermédiaire (avec modification possible), sélection du payeur, puis récapitulatif et paiement. Jusqu'à 10 membres par soumission.
Paiement HelloAsso partagé : pour les paiements HelloAsso, un unique checkout est créé pour l'ensemble des membres inscrits en une fois. Le montant total agrégé est transmis à HelloAsso ; la référence du checkout intent est stockée sur chaque paiement pour assurer la traçabilité.
Sélection flexible du payeur : le responsable peut désigner comme payeur l'un des adhérents, l'un de leurs responsables légaux, ou renseigner manuellement les coordonnées d'un tiers.
Responsables légaux (tuteurs) : chaque adhérent peut déclarer un ou plusieurs responsables légaux avec nom, email, téléphone et type de relation. Un tuteur peut être sélectionné directement comme payeur.
Auto-sélection des rubriques à proposition unique : si une rubrique requise ne contient qu'une seule proposition, elle est pré-sélectionnée automatiquement.
Validation client-side complète : chaque étape du wizard valide localement les champs obligatoires (identité, activités) avant de progresser, sans aller-retour serveur inutile.

Corrections

Navigation retour depuis l'édition d'un adhérent : le bouton "← Précédent" dans l'étape identité d'un adhérent édité depuis la vue transition retournait correctement à la liste de transition plutôt que de ne rien faire.

Modifications

Performance emails : les emails de confirmation sont maintenant envoyés en une seule passe, quel que soit le nombre de membres inscrits en un checkout — plus de ralentissement sur de grands lots.

0.4.4.0 - 2026-04-17

Ajouts

Reçus de paiement PDF : téléchargement et envoi par email depuis la fiche inscription. Le reçu inclut les coordonnées de l'association, les informations de l'adhérent et du payeur, le détail des paiements reçus et les informations réglementaires (RNA, SIRET).
Email "Votre reçu de paiement" : l'adhérent (ou le payeur s'il est renseigné) reçoit le reçu en pièce jointe avec un message récapitulatif.
Adresse postale de l'association : les champs adresse, code postal et ville sont maintenant configurables dans les paramètres de l'association et utilisés dans les reçus PDF.

0.4.3.0 - 2026-04-16

Ajouts

Fiche membre — onglet Activités — nouvel onglet listant les inscriptions du membre, groupées par saison. Chaque inscription affiche le nom de l'activité, les créneaux horaires (jour, heure, durée, salle) et le statut de l'inscription. Un lien vers la fiche cours est disponible pour les utilisateurs ayant accès aux paramètres.
Fiche membre — onglet Payeur (modifier) — deux boutons d'édition permettent désormais de modifier directement l'adresse de facturation et la méthode de paiement préférée via des dialogues modaux, sans quitter la fiche membre.

Corrections

Payeur — effacement des champs adresse — lors de la mise à jour de l'adresse de facturation, envoyer une valeur null vide un champ nullable (ligne 2, région…). Auparavant, la logique ?? ancienne_valeur empêchait de vider ces champs.
Activités — clés de créneaux horaires — les clés de rendu Vue pour les créneaux utilisent désormais dayOfWeek-startTime au lieu de dayOfWeek seul, évitant les doublons lorsqu'un cours a deux plages horaires le même jour.

0.3.2.2 - 2026-04-13

Corrections

Redirection HelloAsso — TypeError corrigé en production — le formulaire d'inscription publique retournait RedirectResponse mais Inertia::location() retourne SymfonyResponse lors d'une requête XHR Inertia. Sans ce correctif, la redirection vers HelloAsso déclenchait un TypeError PHP 8 en production dès qu'un tenant avait ses identifiants HelloAsso configurés, empêchant tout paiement via HelloAsso. Le type de retour de store() est maintenant SymfonyResponse (compatible avec tous les chemins de retour existants).
Champ montant libre — affichage en euros et stockage en centimes — dans le sélecteur de propositions, les champs de montant libre (type custom) affichaient les centimes bruts (ex : 5000 au lieu de 50,00 €) et sauvegardaient la valeur en euros au lieu des centimes. Le correctif divise par 100 à l'affichage et multiplie par 100 à la saisie, alignant le comportement avec le reste du système. Un attribut max="999999.99" est ajouté pour bloquer les valeurs aberrantes côté client.
Tests HelloAsso — compatibilité environnement sandbox — les fakes Http::fake() dans les tests de retour et d'erreur HelloAsso utilisaient le domaine de production (api.helloasso.com) en dur. Avec HELLOASSO_SANDBOX=true, ces tests tentaient une vraie requête réseau. Les patterns sont alignés sur *.helloasso* pour couvrir production et sandbox de manière identique aux helpers existants.

0.3.2.1 - 2026-04-10

Corrections

Page de succès HelloAsso — message affiché selon l'état du paiement — après un paiement HelloAsso, les utilisateurs dont le paiement est encore en cours de traitement voyaient à tort le message "Un email de confirmation vous a été envoyé". La page affiche maintenant une icône horloge et un message "Votre paiement est en cours de traitement" quand le paiement n'est pas encore confirmé, et ne bascule vers le message de confirmation qu'une fois le paiement validé. Le titre de la page s'adapte également (Paiement en cours de traitement ou Inscription confirmée).

0.3.1.0 - 2026-04-09

Ajouts

Paiement HelloAsso en ligne — depuis le formulaire public d'inscription, les visiteurs peuvent désormais payer directement via HelloAsso Checkout. L'association configure ses identifiants OAuth2 et son slug dans les settings, et le bouton "Payer en ligne" apparaît automatiquement sur le wizard.
Page Intégrations (/settings/integrations) — les administrateurs saisissent leur Client ID, Client Secret, slug HelloAsso et secret webhook depuis une interface dédiée. Les secrets ne sont jamais réexposés en frontend après enregistrement.
Webhook HelloAsso (POST /webhook/helloasso/{tenantId}) — endpoint vérifié par signature HMAC-SHA256. Marque le paiement comme reçu, fait passer l'inscription en Paid, et envoie le mail de confirmation exactement une fois (idempotence via confirmation_email_sent_at).
URL de retour HelloAsso (/register/{token}/helloasso/return) — après paiement, vérifie l'état du checkout intent via l'API HelloAsso. Si payé, confirme l'inscription immédiatement. Si l'API est indisponible, affiche un message "en cours de traitement" et laisse le webhook finaliser.
Page d'erreur HelloAsso (/register/{token}/helloasso/error) — affichée si le paiement échoue ou si l'API HelloAsso retourne une erreur. L'inscription orpheline est supprimée automatiquement pour permettre une nouvelle tentative.
Service HelloAssoClient — client HTTP OAuth2 avec cache du token (25 min), support sandbox via HELLOASSO_SANDBOX=true, deux méthodes : createCheckoutIntent() et getCheckoutIntent().
Index payments_reference_index — index standalone sur payments.reference pour les requêtes de fallback du webhook (la contrainte unique UNIQUE(reference, method) existante ne suffit pas pour les lookups par reference seul).

Sécurité

La valeur redirectUrl retournée par HelloAsso est validée contre une liste d'origines autorisées (helloasso.com / helloasso-sandbox.com) avant redirect()->away() pour se prémunir d'une compromission de l'API côté HelloAsso.
Le webhook est exclu du CSRF Laravel et vérifié par HMAC-SHA256 à la place (X-Helloasso-Signature).
Rate limiter du webhook keyé sur tenantId (120 req/h) plutôt que sur l'IP (HelloAsso partage un pool IP entre toutes les organisations).