Journal des modifications

0.16.28.0 — 2026-06-23

Corrections

On reste sur le plan de paiement après une action. Enregistrer, encaisser ou rejeter un versement renvoie désormais vers la page « Plan de paiement » du panier, plus vers le détail du panier.
Barre de paiement lisible quand il n'y a aucun versement. La piste de la barre de progression reçoit une bordure : en thème sombre elle ne disparaît plus sur fond de carte, et le solde restant s'affiche désormais dans la légende.
Pas de reçu en double sur un double-clic. Marquer un versement reçu ou rejeté deux fois de suite (double-soumission) ne ré-envoie plus les e-mails de reçu ni ne réécrit l'historique : l'action est rendue idempotente sous verrou.

Modifications

Saisie d'un versement accessible depuis le détail du panier ET le plan de paiement. La fenêtre de saisie s'ouvre sur place (sans changer de page) ; seul l'enregistrement redirige vers le plan de paiement.
Le trésorier peut saisir et encaisser les versements (la saisie exige la permission de mise à jour des adhérents).

Sécurité

Isolation par association renforcée à la saisie d'un versement : un moyen de paiement personnalisé d'une autre association est refusé, et le paiement en ligne HelloAsso ne peut plus être choisi comme moyen de saisie manuelle.

0.16.23.1 — 2026-06-18

Modifications

Optimisation du fichier CLAUDE.md (instructions agent). Fusion des trois sections de délégation (Task Delegation, Skill routing, Subagents) en une seule, ajout d'une politique de choix de modèle pour les subagents (haiku/sonnet/opus) avec garde sur les frontières hexagonales/DDD et les audits sécurité/RGPD, condensation des sections Docs et Gstack Plans, retrait du contenu superflu. Le bloc laravel-boost-guidelines reste inchangé (auto-géré par boost:install). Changement de documentation outillage uniquement, sans impact applicatif.
Allègement des descriptions de subagents (.claude/agents/). Les frontmatter description: de filament-admin-builder, laravel-model-architect, rgaa-v4-auditor et vue-inertia-dev (blocs <example> verbeux, ~10 ko cumulés chargés à chaque session) sont réduits à un trigger concis (~0,9 ko), mots-clés de routage préservés. Le corps des agents (chargé seulement à l'invocation) est inchangé. Réduit le contexte de démarrage.

0.16.15.0 — 2026-06-12

Ajouts

Export CSV de la liste des inscriptions : un bouton « Exporter CSV » sur la page des inscriptions télécharge exactement le jeu filtré à l'écran (mêmes saison, campagne, cours, statut, recherche), y compris en mode « Toutes les saisons ». Pensé pour la transmission au trésorier / à la comptabilité : colonnes financières (montant dû, total payé, solde) et de réconciliation (saison, campagne, cours), sans donnée d'e-mail.
Permission dédiée « Exporter les inscriptions » : l'export est réservé aux rôles qui en disposent (administrateur et trésorier par défaut), distincte de la simple consultation de la liste. À ré-attribuer aux rôles concernés après déploiement (re-seed des permissions).

Modifications

Fichier CSV adapté au tableur français : séparateur point-virgule et marque d'ordre des octets (BOM) pour une ouverture propre dans Excel/LibreOffice en français, avec accents corrects. Les montants sont exportés en centimes entiers pour une addition fiable quelle que soit la configuration régionale.

Sécurité

Protection anti-injection de formule mutualisée dans un trait partagé : les valeurs texte commençant par =, +, -, @ (etc.) sont neutralisées dans tous les exports CSV (inscriptions et membres d'un cours). Les colonnes numériques ne sont jamais altérées (un solde négatif reste un nombre).

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.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.4.7.0 - 2026-04-22

Corrections

Sécurité multi-tenant : MeetingReport manquait le trait BelongsToTenant — les comptes-rendus n'étaient pas filtrés par tenant. Migration de backfill ajoutée (tenant_id sur meeting_reports).
Injection cross-réunion : il était possible d'envoyer l'ID d'un participant d'une autre réunion dans updateAttendance. La validation Rule::exists scopée sur meeting_id bloque désormais ces requêtes au niveau FormRequest.
N+1 sur la présence : les mises à jour de présence faisaient une requête SQL par participant. Remplacé par batchUpdateAttendance() qui groupe les UPDATE par statut.
Dégradation du statut de rapport : fermer une réunion avec des notes écrasait silencieusement un rapport Validated en Draft via updateOrCreate. Remplacé par un create/update explicite qui préserve le statut existant.
Double validation : il était possible de valider un rapport déjà validé. Garde abort_unless(Draft) ajoutée.
Contenu vide validé : un rapport sans contenu (ou contenu en espaces) pouvait être validé. Garde abort_if(blank()) ajoutée.
Annulation impossible : tenter d'annuler une réunion déjà terminée ou annulée renvoyait une erreur non gérée. Retourne maintenant 422.
Réactivité Vue : le contenu du rapport ne se synchronisait pas après une navigation Inertia. Watch ajouté sur props.meeting.report?.content.

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.3 - 2026-04-13

Corrections

Sécurité — validation serveur du montant unitaire — le contrôleur d'inscription publique acceptait n'importe quel unit_amount sans vérification, permettant à un utilisateur malveillant de soumettre 0 € pour une proposition à prix fixe. La FormRequest impose maintenant que le unit_amount corresponde exactement au amount de la proposition pour les types fixed, et soit nul pour les types free. Les propositions custom (montant libre) acceptent tout montant ≥ 0.
Bug — propositions gratuites bloquaient le formulaire — dans CampaignPropositionSelector.vue, les propositions de type free n'initialisaient pas unit_amount lors de la sélection (radio ou checkbox). Le JSON envoyé ne contenait pas la clé unit_amount, déclenchant l'erreur de validation required côté serveur et laissant l'utilisateur bloqué à l'étape 2 avec une erreur impossible à corriger. Le champ unit_amount est maintenant systématiquement initialisé à 0 pour tous les types non-fixed.
UX — navigation automatique vers l'étape en erreur — après une soumission rejetée par le serveur, l'utilisateur restait bloqué à l'étape 4 (récapitulatif) sans voir les erreurs de validation sur les étapes précédentes. Des watchers Vue naviguent maintenant automatiquement vers l'étape 1, 2 ou 3 dès qu'une erreur serveur est détectée sur les champs correspondants. Le watcher de l'étape 1 inclut désormais un guard currentStep.value > 1 pour éviter une navigation intempestive.

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

0.1.0 - MVP Alpha - 2025-12-24

Version initiale du MVP Alpha.

Ajouts

Architecture multi-tenant avec isolation par sous-domaines
Gestion complète des membres (CRUD, import CSV, exports)
Système d'authentification avec invitation
Panel d'administration Filament
Stack technique: Laravel 12, Vue 3, Inertia v2, Tailwind 4
Tests (Pest v4) avec couverture complète
Documentation technique complète

Légende des types de changements:

Added : Nouvelles fonctionnalités
Changed : Modifications de fonctionnalités existantes
Deprecated : Fonctionnalités dépréciées
Removed : Fonctionnalités supprimées
Fixed : Corrections de bugs
Security : Correctifs de sécurité