Journal des modifications

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.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.10.1.0 — 2026-05-14

Modifications

• Wizard d'inscription public — activités en premier : l'ordre des étapes est désormais Activités → Identité (était Identité → Activités). L'adhérent choisit ses activités avant de remplir ses coordonnées, ce qui réduit la friction mentale à l'entrée du formulaire. La navigation multi-membres (Précédent/Suivant entre membres, édition depuis la transition, retour via le MembersStrip) est entièrement mise à jour pour refléter ce nouvel ordre.

0.7.0.0 — 2026-05-12

Ajouts

• Flux d'invitation RGPD : les administrateurs peuvent inviter des membres et des employés par email. Le destinataire reçoit un lien signé (valide 72h) lui permettant de créer son compte (prénom, nom, email pré-remplis, mot de passe, consentement RGPD). L'invitation est marquée "utilisée" à l'issue de la création. Les employés ne voient pas le champ consentement (non applicable).
• Trois types d'invitation : member (crée un nouveau member + person), member_linked (lie le compte à un adhérent existant sans doublon), employee (crée un compte sans member associé).
• Pré-remplissage du formulaire d'inscription : prénom et nom de l'invité sont pré-remplis depuis l'invitation et rendus non-modifiables si renseignés.
• Test de couverture du flux réel : test d'intégration qui valide la chaîne complète GET-signed URL → POST → redirection, garantissant que l'ordre alphabétique des paramètres signés est préservé jusqu'à la validation HMAC.

Corrections

• 403 « Invalid Signature » à la soumission du formulaire d'invitation : le composant Vue reconstituait les paramètres de query string dans un ordre différent de celui du lien signé (alphabétique, imposé par Laravel ksort()). La validation HMAC étant sensible à l'ordre, cela produisait un 403 systématique. Corrigé en passant directement window.location.search sans reconstruction.
• Sécurité et robustesse de l'InvitationController : l'invitation_id est désormais vérifié en database plutôt qu'ignoré silencieusement ; les domaines d'email autorisés sont validés côté serveur pour les invitations employee.
• Erreurs PHPStan : remplacement des opérateurs ?-> sur la gauche d'un ?? par des guards explicites.
• Doublons d'écouteurs d'événements : suppression des Event::listen() manuels redondants qui dupliquaient les listeners déjà enregistrés via $listen.

Modifications

• Consolidation du use case d'inscription : les trois use cases distincts (CreateMemberUserUseCase, CreateEmployeeUseCase, LinkMemberAccountUseCase) sont fusionnés en un seul RegisterUserFromInvitationUseCase qui gère les trois variantes via un match sur user_type. Moins de duplication, traçabilité unifiée.

0.6.1.0 — 2026-05-11

Ajouts

• Liaison compte utilisateur ↔ adhérent existant : vous pouvez maintenant créer un compte utilisateur directement lié à un adhérent déjà présent dans la base — sans recréer de doublon. Le formulaire affiche un sélecteur de recherche qui liste uniquement les adhérents sans compte, scoped au tenant.
• Picker adhérent accessible : le sélecteur (MemberPickerForm) est un combobox conforme ARIA (role="combobox", role="listbox", aria-expanded) avec auto-complétion, badge de sélection avec bouton de désélection, et pré-remplissage automatique de l'email depuis la fiche adhérent.
• Filtre "Sans compte" sur la liste des membres : un nouveau filtre permet d'afficher uniquement les adhérents qui n'ont pas encore de compte utilisateur — utile pour piloter le déploiement progressif des accès.

Corrections

• Doublons Person/Member à la création de compte : la création d'un compte utilisateur réutilise désormais une personne et un membre existants (même email, même tenant) au lieu d'en créer de nouveaux. Aucune donnée orpheline.
• Erreur de chargement silencieuse : si l'endpoint /settings/users/available-members est inaccessible (réseau, 403, 500), le picker affiche maintenant un message d'erreur visible plutôt qu'une liste vide sans explication.

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.2.0 - 2026-04-16

Modifications

• Fiche membre — onglet Identité — les informations sont désormais organisées en cartes distinctes : Identité (prénom, nom, date de naissance), Contact (email, téléphone), Adresse, Consentements RGPD, et Responsables légaux. Auparavant, email et téléphone étaient regroupés avec le prénom/nom sous "Informations personnelles".
• Fiche membre — onglet Identité — la section "Responsables légaux" est maintenant intégrée directement dans l'onglet Identité (au lieu d'être affichée en dehors des onglets, en bas de page), ce qui améliore la cohérence de navigation.
• Fiche membre — onglet Adhérent — la carte "Documents acceptés" (statuts de l'association, règlement intérieur) est fusionnée avec la carte "Historique" sous le titre "Documents & Historique". La carte "Payeurs associés" occupe désormais toute la largeur.
• Libellés — "Type d'abonnement" renommé en "Type d'adhésion" dans l'onglet Adhérent.

Corrections

• Consentements RGPD — la date de mise à jour affiche "Aucune mise à jour enregistrée" lorsqu'aucune date n'est renseignée, au lieu du texte grammaticalement incorrect "Mis à jour le Non renseigné".

0.4.1.1 - 2026-04-15

Ajouts

• Badge compteur de membres financés — l'onglet "Payeur" de la fiche membre affiche maintenant un badge indiquant le nombre de membres financés par ce payeur, directement sur l'intitulé de l'onglet.

Corrections

• Lien payeur dans la fiche adhérent — le clic sur une carte payeur dans l'onglet "Payeurs associés" d'une fiche membre navigue maintenant correctement vers la fiche de ce membre. Auparavant, le lien pointait vers /persons/{id} (route inexistante) et retournait une 404. Un payeur sans compte adhérent affiche une carte non-cliquable (cursor-default) au lieu d'un lien cassé vers #.
• Lien membres financés dans l'onglet payeur — le clic sur un membre financé dans l'onglet "Payeur" d'une fiche navigue maintenant correctement vers la fiche de ce membre adhérent. Le lien utilisait personId au lieu de id (l'identifiant du membre) et retournait une 404.