Journal des modifications
Les évolutions de Cohez.io, de la plus récente à la plus ancienne.
93 versions correspondent à « inscription ».
Versions 61 à 70 sur 93
0.14.0.0 — 2026-05-29
Ajouts
- Gestion des documents officiels de l'association : les administrateurs peuvent désormais déposer et supprimer les statuts et le règlement intérieur depuis les paramètres de l'association. Les documents sont stockés de façon privée sur S3 (Clever Cloud Cellar) avec des URLs temporaires signées (30 min). Un seul document actif par type est conservé ; un nouvel upload archive automatiquement le précédent.
- Consultation des documents depuis le formulaire public d'inscription : quand un document officiel est disponible, un lien « Lire les statuts » / « Lire le règlement intérieur » apparaît dans le formulaire d'inscription (étape Identité). Le lien reste accessible même si la campagne est clôturée, mais expire avec le token d'inscription.
- Audit de cohérence S3/DB (
php artisan documents:audit) : commande hebdomadaire qui détecte et peut supprimer (--delete) les fichiers orphelins présents sur S3 mais absents de la base de données.
Corrections
- ConfirmDialog : suppression silencieuse sur toute l'application :
ConfirmDialog.vueémettaitupdate:open(false)avantconfirm, ce qui effaçait l'identifiant de la ressource à supprimer avant que le handler parent ne soit exécuté. La suppression ne déclenchait jamais la requête serveur. Correction :confirmest émis en premier. Ce bug affectait les 17+ utilisations deConfirmDialogdans l'app (membres, groupes, réunions, documents, etc.). - Liens documents non cliquables dans le formulaire d'inscription public : les liens « Lire les statuts / règlement » utilisaient le composant
<Link>d'Inertia qui appellepreventDefault(), empêchant l'ouverture du PDF. Rétablis en<a target="_blank">.
0.13.9.0 — 2026-05-28
Ajouts
- Archivage des propositions de campagne : une proposition peut désormais être désactivée (archivée) sans être supprimée, via le bouton « Désactiver » dans le constructeur de campagne. Les propositions archivées sont masquées du formulaire public d'inscription et du formulaire admin de création d'inscription ; elles restent visibles dans une section « Désactivées » repliable pour les gestionnaires. Une proposition archivée peut être réactivée à tout moment.
Corrections
- Suppression de proposition bloquée si des inscriptions existent : tenter de supprimer une proposition liée à au moins une inscription retourne désormais un message d'erreur explicite au lieu d'une exception non gérée (
RESTRICTFK violation). - Propositions archivées accessibles via le flux admin :
StoreRegistrationRequestn'appliquait pas le filtrewhereNull('archived_at')surproposition_id, permettant de soumettre une proposition archivée depuis le backoffice.
0.13.8.0 — 2026-05-27
Corrections
- Backoffice inscriptions — notes JSON visibles : les métadonnées internes HelloAsso stockées dans le champ
notesdu 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
itemNameenvoyé à l'API HelloAsso contenait un tiret em (U+2014) dans le libelléAcompte — Inscription …, rejeté avec l'erreurArgumentInvalid / 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 (brancheguardiannon gérée). L'email est maintenant correctement récupéré depuismembers[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
payerEmailLocalErrorest 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 correctementeditingIdentityFromTransitionmais laissaiteditingMemberFromTransitionactif 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: colonnedescription TEXT NULLsurtenant_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é avecforeachpour résoudre PHPStan null-safe sur$p->courseet eager loadingpropositions.courseajouté.- 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 surpersons.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
isActivityexposé 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 » et2026-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): ?stringdansPublicRegistrationControllerpour dédupliquer le pattern Money/EUR/garde->0répété 3× dansstore(). - 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.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.