Journal des modifications

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.14.2.0 — 2026-06-01

Modifications

Confirmation des paiements HelloAsso : la logique de confirmation (paiement reçu, transition de statut, envoi d'email) est désormais centralisée dans un service dédié, éliminant trois implémentations divergentes (retour URL, webhook, commande de synchronisation). Les guards d'idempotence sont désormais uniformes sur tous les états terminaux (Received, Rejected, Refunded, Contested).
Checkout HelloAsso : les deux blocs de création de paiement dans le formulaire d'inscription (paiement standard et acompte) sont fusionnés en un service unique.

Corrections

L'événement RegistrationValidated (déclenchant la création de facture et l'email de confirmation) est maintenant émis après le commit de la transaction de paiement, garantissant que les listeners synchrones opèrent sur des données pleinement persistées.
L'idempotence du retour HelloAsso ignorait les états Rejected, Refunded et Contested — désormais alignée avec le webhook.

0.14.1.4 — 2026-06-01

Ajouts

Couverture complète des états de paiement HelloAsso : le webhook et la commande helloasso:sync-pending-payments gèrent désormais tous les états HelloAsso — Refused → Rejected, Refunding/Refunded → Remboursé, Contested → Contesté. L'interface affiche les badges correspondants avec les variantes visuelles adaptées.

Corrections

Guard d'idempotence webhook étendu : lors d'un retry de webhook Paid, le handler vérifie maintenant tous les états terminaux (Received, Refunded, Contested, Rejected) avant d'écrire — empêchant un webhook retardé d'écraser un remboursement déjà enregistré.
Guard d'idempotence sync étendu : helloasso:sync-pending-payments applique le même guard (tous les états terminaux) pour éviter qu'une exécution concurrente avec un webhook ne réécrive un paiement Refunded/Contested avec Received.
Filtre méthode de paiement dans resolvePayments() : les paths 1 et 2 de résolution (par registration_ids[] et registration_id) filtraient tous les paiements d'une inscription ; ils filtrent maintenant uniquement ceux de méthode HelloAsso, évitant de marquer des paiements espèces/chèque comme rejetés/remboursés.
Compteur --dry-run : le compteur de paiements mis à jour n'était pas incrémenté dans le bon bloc conditionnel pour les checkouts refusés, affichant un compte erroné en mode dry-run.
Types TypeScript : Payment.status dans la page inscription inclut désormais 'refunded' et 'contested' ; les badges s'affichent correctement pour ces états.

0.14.1.3 — 2026-05-30

Ajouts

Commande helloasso:sync-pending-payments : nouvelle commande artisan pour récupérer les paiements HelloAsso restés en attente après un webhook manquant. Pour chaque tenant avec credentials HelloAsso, interroge l'API pour tous les paiements Pending ayant une référence, et confirme automatiquement ceux qui sont payés (transition Draft → Validated, email de confirmation). Options : --tenant=UUID pour restreindre à un seul tenant, --dry-run pour prévisualiser sans modifier.

Corrections

Webhook HelloAsso sans webhook_secret : les tenants sans clé partenaire HelloAsso recevaient 401 Webhook secret not configured sur chaque notification, laissant les paiements en Draft indéfiniment. Le webhook accepte désormais les requêtes provenant des IPs officielles HelloAsso (51.138.206.200 prod, 4.233.135.234 sandbox) quand aucun secret n'est configuré — conformément à la méthode de validation documentée par HelloAsso pour les non-partenaires.
Rejet HelloAsso sur lastName invalide : l'API HelloAsso rejetait l'erreur Le champ nom est invalide quand le nom du payeur contenait un seul caractère, des chiffres ou des accents non supportés (ü, ñ…). Les champs firstName/lastName du payeur sont maintenant omis du checkout intent — HelloAsso les collecte directement sur sa page de paiement.

0.14.1.2 — 2026-05-29

Corrections

Régression HelloAsso : après le déploiement de la configuration per-tenant (v0.14.1.0), les tenants sans flag hello_asso_sandbox explicite se retrouvaient en mode production par défaut, causant une erreur 401 unauthorized pour ceux utilisant des credentials sandbox — et donc aucune redirection vers HelloAsso. helloAssoSandbox() retombe désormais sur la variable d'environnement globale HELLOASSO_SANDBOX pour les tenants non encore configurés individuellement, préservant le comportement antérieur au déploiement.

0.14.1.1 — 2026-05-29

Corrections

Modal HelloAsso : le Radio "sandbox / production" affiche maintenant l'environnement actuel du tenant à l'ouverture de la modale (correction de la valeur initiale manquante via ->fillForm()).

0.14.1.0 — 2026-05-29

Ajouts

Configuration HelloAsso per-tenant (sandbox / production) : chaque tenant peut désormais utiliser un environnement HelloAsso distinct. Un super-admin bascule le mode depuis la fiche Filament via le bouton "Environnement HelloAsso" — un modal avec sélection Radio et confirmation obligatoire ("PRODUCTION") protège contre les clics accidentels. Le badge SANDBOX/PRODUCTION est visible en temps réel dans l'infolist. Le token OAuth2 est automatiquement invalidé lors du changement d'environnement.
Bandeau "Mode test HelloAsso" dans le wizard d'inscription public : quand un tenant est en mode sandbox, un bandeau amber persistant ("Aucun paiement réel ne sera encaissé") s'affiche sur toutes les étapes du formulaire, empêchant toute confusion entre paiements réels et tests.

0.14.0.0 — 2026-05-29

Ajouts

Gestion des documents officiels de l'association : les administrateurs peuvent désormais déposer et supprimer les statuts et le règlement intérieur depuis les paramètres de l'association. Les documents sont stockés de façon privée sur S3 (Clever Cloud Cellar) avec des URLs temporaires signées (30 min). Un seul document actif par type est conservé ; un nouvel upload archive automatiquement le précédent.
Consultation des documents depuis le formulaire public d'inscription : quand un document officiel est disponible, un lien « Lire les statuts » / « Lire le règlement intérieur » apparaît dans le formulaire d'inscription (étape Identité). Le lien reste accessible même si la campagne est clôturée, mais expire avec le token d'inscription.
Audit de cohérence S3/DB (php artisan documents:audit) : commande hebdomadaire qui détecte et peut supprimer (--delete) les fichiers orphelins présents sur S3 mais absents de la base de données.

Corrections

ConfirmDialog : suppression silencieuse sur toute l'application : ConfirmDialog.vue émettait update:open(false) avant confirm, ce qui effaçait l'identifiant de la ressource à supprimer avant que le handler parent ne soit exécuté. La suppression ne déclenchait jamais la requête serveur. Correction : confirm est émis en premier. Ce bug affectait les 17+ utilisations de ConfirmDialog dans l'app (membres, groupes, réunions, documents, etc.).
Liens documents non cliquables dans le formulaire d'inscription public : les liens « Lire les statuts / règlement » utilisaient le composant <Link> d'Inertia qui appelle preventDefault(), empêchant l'ouverture du PDF. Rétablis en <a target="_blank">.

0.13.9.0 — 2026-05-28

Ajouts

Archivage des propositions de campagne : une proposition peut désormais être désactivée (archivée) sans être supprimée, via le bouton « Désactiver » dans le constructeur de campagne. Les propositions archivées sont masquées du formulaire public d'inscription et du formulaire admin de création d'inscription ; elles restent visibles dans une section « Désactivées » repliable pour les gestionnaires. Une proposition archivée peut être réactivée à tout moment.

Corrections

Suppression de proposition bloquée si des inscriptions existent : tenter de supprimer une proposition liée à au moins une inscription retourne désormais un message d'erreur explicite au lieu d'une exception non gérée (RESTRICT FK violation).
Propositions archivées accessibles via le flux admin : StoreRegistrationRequest n'appliquait pas le filtre whereNull('archived_at') sur proposition_id, permettant de soumettre une proposition archivée depuis le backoffice.

0.13.8.0 — 2026-05-27

Corrections

Backoffice inscriptions — notes JSON visibles : les métadonnées internes HelloAsso stockées dans le champ notes du paiement (objet JSON {"checkout_type":"deposit","checkout_url":"…"}) s'affichaient en clair dans l'historique des paiements. Ces notes internes (débutant par {) sont désormais masquées dans la vue.