Journal des modifications

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

0.13.7.0 — 2026-05-27

Corrections

Checkout HelloAsso dépôt (ArgumentInvalid) : le champ itemName envoyé à l'API HelloAsso contenait un tiret em (U+2014) dans le libellé Acompte — Inscription …, rejeté avec l'erreur ArgumentInvalid / Le champ nom est invalide. Remplacé par un tiret simple pour les deux paths (checkout dépôt et checkout standard). Les tirets em éventuellement présents dans le nom de campagne sont également sanitisés.

0.13.2.1 — 2026-05-25

Modifications

Documentation synchronisée avec le code : audit complet de Docs/ — corrections des décalages entre la documentation et l'implémentation réelle (enum PaymentMethod, statut Abandoned, champ reply_to_email vs email, contrainte rna VARCHAR(10), format registration_ids dans les exemples HelloAsso, champ transcript des réunions, routes actives des membres). Le fichier Docs/Development/Multi-Tenant-TODOs.md est archivé dans Docs/Archive/.
Plans et specs gstack déplacés hors dépôt : les fichiers de planification générés par les outils IA (Docs/superpowers/) sont désormais stockés hors du dépôt et n'apparaissent plus dans les diffs de PR.

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.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.9.0.0 — 2026-05-13

Ajouts

Contrôle de capacité des cours : les inscriptions (admin et publiques) sont désormais bloquées quand un cours est complet. Protection à deux niveaux : fast-fail UX dans le FormRequest (withValidator()) + check atomique avec lockForUpdate() dans une transaction pour gérer la concurrence.
Badge « Complet » sur les propositions : dans le formulaire d'inscription public, les propositions rattachées à un cours complet affichent un badge warning « Complet » et désactivent la sélection (radio/checkbox grisés).
Course::enrolledCountCurrent() : compteur d'inscrits actifs excluant les statuts cancelled et refused (les inscriptions draft comptent pour réserver la place lors d'un checkout HelloAsso en cours).
Course::isFull() : expose l'état de complétude du cours, basé sur enrolledCountCurrent() pour une sémantique cohérente avec le check transactionnel.

Corrections

Incompatibilité PostgreSQL FOR SHARE + agrégat : suppression du sharedLock() de enrolledCountCurrent() — FOR SHARE est rejeté par PostgreSQL sur les requêtes avec COUNT. La sérialisation atomique est garantie par le lockForUpdate() sur la ligne Course dans la transaction du contrôleur.
Test LegalGuardianControllerTest flaky : PersonFactory génère des emails via safeEmail() qui peut contenir le prénom jean ; la recherche dans searchPersons() porte aussi sur l'email, produisant un résultat inattendu selon ORDER BY last_name ASC. Corrigé avec des emails déterministes dans le beforeEach.

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.1.0 - 2026-04-14

Ajouts

Chiffrement des secrets tenant — les clés API HelloAsso (hello_asso_client_secret, hello_asso_webhook_secret) sont maintenant chiffrées au repos dans la colonne settings JSON du tenant via un cast Eloquent EncryptedSettingsCast. Toute clé dont le nom se termine par _secret est automatiquement chiffrée en écriture et déchiffrée en lecture (AES-256-CBC via APP_KEY). L'accès depuis le code applicatif est transparent.
Rotation d'APP_KEY — support de APP_PREVIOUS_KEYS pour déchiffrer les secrets chiffrés avec une ancienne clé sans interruption de service. La commande php artisan settings:reencrypt-secrets re-chiffre tous les secrets sous la clé courante pour permettre de vider APP_PREVIOUS_KEYS après rotation.
Migration de données idempotente — la migration encrypt_tenant_settings_secrets chiffre les secrets existants en clair dans la base de production. L'opération est idempotente (les blobs déjà chiffrés sont ignorés) et peut être réexécutée sans risque.
Commande de re-chiffrement en deux phases — settings:reencrypt-secrets opère en phase 1 (lecture et validation de tous les secrets) puis phase 2 (écriture), de sorte qu'une erreur de déchiffrement sur un tenant annule l'opération avant qu'une seule écriture ait lieu.
UX intégrations — masquage des secrets existants — le formulaire de configuration HelloAsso affiche un placeholder "Configuré — laisser vide pour conserver" lorsqu'un secret est déjà enregistré, évitant d'exposer la valeur et signalant clairement que le champ peut être laissé vide.
Confirmation du mot de passe sur la page intégrations — la sauvegarde des identifiants HelloAsso requiert maintenant la confirmation du mot de passe courant de l'utilisateur.

Sécurité

Les secrets API HelloAsso ne sont plus stockés en clair dans la base de données. La colonne settings contient désormais des blobs chiffrés AES-256-CBC pour toutes les valeurs dont la clé se termine par _secret.

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.