Journal des modifications

0.18.3.0 — 2026-07-01

Ajouts

Refactoring MemberController::show() → CQRS read model (GetMemberDetailQuery) : la méthode show() passe de 263 lignes à ~12 lignes en déléguant à une query orchestratrice qui coordonne 7 assembleurs, chacun produisant un DTO final readonly typé. Les DTOs couvrent : PersonSectionData, MemberSectionData, UsagerSectionData, LegalGuardianData, PayeurSectionData, RegistrationSummaryData, MeetingActionData.
Limitation des inscriptions à 50 + hasMoreRegistrations : la query charge 51 inscriptions (LIMIT+1), n'en retourne que 50, et expose le flag hasMoreRegistrations pour signaler qu'il y en a davantage — sans pagination complète.
Migration index composite (tenant_id, responsible_user_id, due_date) sur meeting_actions : élimine le filesort sur ORDER BY due_date LIMIT 50 dans MeetingActionsAssembler.

Corrections

tenant_id ajouté aux selects contraints sur legalGuardians.person.adherent et payeurs.person.adherent (évite un null silencieux si $adherent->tenant_id est accédé ultérieurement).
toISOString() dans MeetingActionsAssembler (cohérence avec les autres assembleurs qui utilisaient déjà cette forme).
MemberDetailResponse::$member déclaré non-nullable (toujours valorisé par memberAssembler->assemble()).

Tests

Test 403 sur members.show sans permission (couverture manquante sur l'accès à la fiche membre).
Test LIMIT+1 (hasMoreRegistrations) avec 51 campagnes distinctes pour contourner la contrainte unique (member_id, campaign_id).
Test ModelNotFoundException sur un member_id inexistant.
Test isolation cross-tenant sur MeetingActionsAssembler : vérifie que le scope BelongsToTenant filtre les actions d'un autre tenant même si responsible_user_id est identique.
Test positif MeetingActionsAssembler avec fixture MeetingAction réelle (l'ancien test ne créait aucune action).

0.18.2.0 — 2026-06-30

Ajouts

Visibilité publique des moyens de paiement (is_public) : nouveau flag indépendant de is_enabled sur TenantPaymentMethod. Permet de configurer un moyen de paiement disponible uniquement en back-office (ex. CB physique, virement interne) sans l'exposer sur le formulaire public d'inscription.
Toggle « Proposé au public » dans les paramètres moyens de paiement : second interrupteur par méthode (désactivé si la méthode est désactivée). Désactiver une méthode force automatiquement is_public = false côté serveur.
Méthodes custom dans la saisie de versement back-office : les méthodes custom activées (payment_method IS NULL) sont désormais proposées dans le dialog « Enregistrer un versement », avec validation du custom_payment_method_id.
Scope scopePublic() sur TenantPaymentMethod : filtre is_enabled = true AND is_public = true, utilisé par le formulaire public d'inscription.

Modifications

Le formulaire public d'inscription filtre désormais les moyens de paiement via scopePublic() (au lieu de scopeEnabled()) — seules les méthodes activées et marquées publiques sont proposées.

0.18.1.0 — 2026-06-29

Ajouts

Formulaire pleine page « Ajouter un inscrit » (AddCartMember.vue) : parcours guidé en 3 étapes (Identité → Activités → Récapitulatif) pour ajouter un membre à un panier depuis le back-office. Supporte la sélection d'un membre existant ou la création inline d'un nouveau membre (avec tuteur légal pour les mineurs). Les membres déjà actifs dans le panier sont automatiquement exclus de la liste.
Test d'isolation cross-tenant sur CartMutationControllerTest : vérifie que le scope BelongsToTenant rend un panier invisible hors de son tenant (couche Eloquent).

Modifications

MemberForm : nouveau mode simplifié (simplified) pour les contextes d'inscription back-office — masque les champs non nécessaires (photo, bio, nationalité…) et réduit le formulaire aux données essentielles.

Corrections

Performance : requête availableMembers dans buildPanierPayload — ajout de ->with('person') (évite N+1 sur l'accesseur first_name/last_name) et ->limit(200) (borne la requête pour les tenants avec de nombreux membres).

0.18.0.0 — 2026-06-29

Ajouts

Gérer le panier — CartMutationService : trois nouvelles opérations atomiques sur le panier, chacune sous verrou lockForUpdate global sur toutes les inscriptions du panier :
- Ajouter un inscrit : sélection d'un membre existant (liste filtrée — inscrits actifs exclus) ou création inline d'un nouveau membre, avec choix du/des cours. Les tarifs multi-membres sont recalculés pour l'ensemble du panier à chaque ajout. La facture de chaque inscription déjà facturée est re-versionnée.
- Déplacer un cours : transfert atomique d'un cours d'un inscrit vers un autre inscrit du même panier. Les deux inscriptions sont recalculées et leur facture re-versionnée dans la même transaction.
- Supprimer le panier : annulation de toutes les inscriptions non-terminales avec remise à zéro des montants. Bloqué si des versements encaissés existent (atomique — vérification sous verrou).
Dialogs back-office sur la page « Détail du panier » : trois dialogs dédiés (Ajouter un inscrit, Déplacer un cours, Supprimer le panier) accessibles via un menu « Gérer le panier ». Les actions destructives nécessitent une confirmation explicite.
Sécurité — isolation tenant renforcée : les propositions sont désormais scopées explicitement au tenant du gestionnaire (via rubriques.tenant_id) dans les Form Requests et dans le contrôleur, en complément de la vérification campaign_id existante dans le service.

Corrections

Sécurité : la vérification de versements encaissés dans deleteCart est désormais effectuée à l'intérieur de la transaction sous lockForUpdate, éliminant une fenêtre de race condition entre la vérification et l'annulation des inscriptions.

0.17.0.0 — 2026-06-29

Ajouts

Panneau paiement inline dans le détail panier : récap des versements (montant, statut, méthode, dates prévue/reçue, référence, notes) et formulaire d'ajout directement sur la page détail panier — plus besoin d'ouvrir une modale ou de naviguer vers le plan de paiement.

Modifications

Enregistrer un versement redirige désormais vers la page d'origine (détail panier ou plan de paiement) au lieu de forcer la navigation vers le plan de paiement.
Le détail panier expose les données complètes des versements (dates, référence, notes) au lieu d'un simple statut.

Corrections

Sécurité : la redirection post-enregistrement de versement est désormais restreinte aux routes autorisées du panier (protège contre une éventuelle manipulation du header Referer).

0.16.33.0 — 2026-06-26

Ajouts

Versioning immuable du panier (cart snapshot). Chaque validation d'inscription et chaque mutation de cours (ajout, retrait, échange) crée désormais un snapshot versionné du panier, archivant les tarifs, remises et composition à l'instant t. La facture PDF lit systématiquement depuis ce snapshot ; le contenu de la facture est ainsi figé même si les inscriptions évoluent ultérieurement.
Annulation avec recalcul automatique. L'annulation d'une inscription réindexe les member_index des inscrits restants et recalcule leurs tarifs (remises multi-membres incluses) de manière atomique. Un nouveau snapshot est créé après l'annulation pour refléter l'état final du panier.

Modifications

La facture PDF d'un panier (/facture-pdf) affiche désormais les inscriptions annulées de façon distincte (montant à 0, lignes vides) et les exclut du total et des remises affichés.
Le total du panier et les remises dans le back-office excluent les inscriptions terminales (annulées, refusées) — seules les inscriptions actives contribuent aux montants affichés.
Le statut de paiement "Encaissé" est renommé "Reçu" dans l'interface.

Corrections

La route /facture-pdf ne plante plus avec function max(uuid) does not exist sur PostgreSQL (la relation latestSnapshot utilisait ofMany() qui génère un MAX(id) incompatible avec les UUID).

0.16.32.0 — 2026-06-25

Ajouts

Relancer le paiement au niveau du panier. La page « Détail du panier » propose désormais un bouton « Relancer le paiement » qui s'adresse au payeur pour l'ensemble du panier, en un seul envoi. Le mode est choisi automatiquement : si un paiement HelloAsso reste à régler, un lien de paiement est renvoyé ; sinon (chèque, virement, espèces) un rappel récapitulatif liste le solde restant dû de chaque inscrit, le total et la date limite la plus proche. Une fenêtre de confirmation affiche le destinataire et prévient si une relance a déjà été envoyée il y a moins de 24 h. L'historique des relances du panier est visible sur la page. Le panneau est masqué quand le panier est soldé et pour un compte en lecture seule ; l'isolation entre associations est garantie (un panier d'une autre association renvoie une 404).

0.16.31.0 — 2026-06-25

Ajouts

Facture du panier en un coup d'œil + export PDF. La page « Détail du panier » affiche désormais une facture consolidée regroupant chaque inscrit, ses prestations et le total facturé (remises comprises). Un bouton « PDF » génère une facture agrégée du panier (une seule pièce pour l'ensemble des inscrits), sur le même modèle que les reçus existants.
Note interne au niveau du panier. Le gestionnaire peut saisir et modifier une note interne attachée au panier (paiement échelonné convenu, certificat reçu…), visible directement sur la page « Détail du panier ». La note n'est éditable que par un compte disposant de la mise à jour des adhérents ; un compte en lecture seule la consulte sans pouvoir la modifier. L'isolation entre associations est garantie (un panier d'une autre association renvoie une 404).

0.16.30.1 — 2026-06-24

Modifications

Nettoyage : suppression d'une donnée inutilisée sur la fiche inscription. La page « Détail d'une inscription » ne charge plus la liste des options de cours (courseOptions), désormais inutile depuis que la gestion des cours a migré vers la page « Détail du panier ». Allègement de la charge réseau, sans changement visible pour l'utilisateur.

0.16.30.0 — 2026-06-24

Modifications

Gérer une inscription sans quitter le panier. Les actions par inscription (valider, demander la validation, refuser, annuler, ajouter / retirer / échanger un cours, prolonger l'acompte, envoyer le reçu) s'effectuent désormais directement dans l'accordéon de chaque inscrit sur la page « Détail du panier ». La fenêtre d'aperçu des montants (ajout / retrait / échange de cours) s'ouvre sur place, et chaque action rafraîchit les données sans changer de page. Le panier devient le poste de travail unique du gestionnaire.
Fiche inscription recentrée sur la consultation. La page d'une inscription conserve l'affichage détaillé (facture, notes, historiques) et la carte de relance, mais n'héberge plus les actions migrées ; le lien depuis le panier devient « Voir le détail ».
Aucune action visible pour un compte en lecture seule. Un utilisateur disposant uniquement de la consultation des adhérents ne reçoit aucun contrôle d'action sur le détail du panier (parité avec les contrôles côté serveur).