Journal des modifications

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

0.13.5.0 — 2026-05-26

Corrections

Description par moyen de paiement dans le récapitulatif public : les instructions spécifiques à chaque méthode (ex. : coordonnées bancaires pour un virement) s'affichent désormais sous le libellé dans l'étape récap du wizard d'inscription. Les descriptions sont éditables directement depuis la page Paramètres › Moyens de paiement, pour les méthodes standard et personnalisées.
Acompte ignoré pour les méthodes de paiement personnalisées : lors d'une inscription avec acompte, le déclenchement du dépôt était systématiquement ignoré pour les méthodes personnalisées. La règle d'acompte stocke l'UUID de la méthode dans applicable_payment_methods, mais le service comparait la valeur d'enum 'custom' au lieu de l'UUID — corrigé des deux côtés (service et contrôleur).
Onglet par défaut sur la fiche membre : l'onglet affiché à l'ouverture d'une fiche membre était « Activités » ; il est maintenant correctement positionné sur « Identité ».
Libellé onglet corrigé : l'onglet « Adhérent » est renommé « Adhésion » pour correspondre au contenu affiché.
Noms de cours dans la liste des inscriptions : la colonne campagne affiche maintenant les activités rattachées (ex. : « Yoga débutant ») sous le nom de la campagne, facilitant l'identification rapide.

Interne

Migration add_description_to_tenant_payment_methods_table : colonne description TEXT NULL sur tenant_payment_methods, réversible.
Nouvelle route PATCH /settings/payment-methods/{method} pour la mise à jour de la description (contrôleur, validation, tests).
RegistrationController::index() refactorisé avec foreach pour résoudre PHPStan null-safe sur $p->course et eager loading propositions.course ajouté.
Tests de régression : service-level pour bug 1f (méthode personnalisée + règle d'acompte), controller-level pour bug 2d (courseNames).

0.13.4.0 — 2026-05-26

Corrections

Inscription famille avec email partagé tuteur/enfant : l'inscription d'un mineur dont le tuteur utilise la même adresse email que l'enfant réussit désormais. Auparavant, la déduplication par email seul confondait le tuteur avec l'enfant et provoquait une erreur « déjà inscrit » injustifiée.
Page de succès blanche après inscription : la page de confirmation s'affichait vide à cause d'une propriété Vue 3 non assignée (defineProps() non capturé). Le titre, le statut de paiement et les informations d'acompte s'affichent maintenant correctement.

Interne

Suppression de deux blocs try/catch(UniqueConstraintViolationException) devenus inaccessibles depuis la suppression de la contrainte unique sur persons.email (février 2026).
Test de régression ajouté pour le scénario tuteur/enfant à email partagé, couvrant la création distincte des deux Persons et le flag is_minor.

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.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.2.0 — 2026-05-24

Corrections

Inscription famille avec email partagé : plusieurs membres d'une même famille peuvent désormais utiliser le même email parental lors d'une inscription. La déduplication utilise une identité composite (email + prénom + date de naissance) plutôt que l'email seul — deux enfants avec le même email mais des prénoms ou dates de naissance différents sont traités comme des personnes distinctes. Un index composite (tenant_id, email, first_name, date_naissance) accélère les lookups.

0.13.1.0 — 2026-05-22

Corrections

Double inscription bloquée proprement : soumettre deux fois le formulaire d'inscription pour le même membre et la même campagne déclenchait une erreur 500 (violation de contrainte PostgreSQL registrations_member_campaign_unique). L'administrateur voit désormais un message de validation clair — « Ce membre est déjà inscrit à cette campagne. » — sans erreur serveur.

0.13.0.1 — 2026-05-21

Corrections

Formulaire de prolongation d'acompte visible : le bouton « Prolonger le délai » n'apparaissait plus dans la fiche inscription suite à une comparaison TitleCase des statuts — corrigé en utilisant les valeurs sérialisées (draft, pending_validation).
Dépôt nul ignoré : si la règle d'acompte ne correspond à aucune rubrique des prestations choisies, le calcul retourne 0 € — l'inscription suit désormais le chemin normal sans générer de flux dépôt fantôme.
Prolongation active jusqu'en fin de journée : la nouvelle date-limite est enregistrée à 23:59:59 (fin de journée) plutôt qu'à minuit, évitant l'abandon immédiat par le cron si celui-ci tourne après minuit la même nuit.
Cron dépôts expiré : schedule horaire effectif : le verrou withoutOverlapping est désormais limité à 5 minutes (contre 24 h par défaut), garantissant que le cron tourne bien à chaque heure même après un éventuel blocage.

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.