Aller au contenu
Candidater

Journal des modifications

Les évolutions de Cohez.io, de la plus récente à la plus ancienne.

174 versions publiées.

Versions 61 à 70 sur 174

0.20.0.3 — 2026-07-20

Corrections

  • Responsable légal désormais réellement exigé pour un adhérent mineur sur le funnel public (art. 8 RGPD) : le libellé du formulaire annonçait un responsable légal « obligatoire » pour un mineur, mais rien ne le validait ni côté serveur ni côté client — une soumission sans tuteur passait. date_naissance passe de nullable à required (impossible de déterminer la minorité sans elle) et SubmitPublicRegistrationRequest::withValidator() bloque désormais toute soumission d'un membre de moins de 18 ans sans au moins un guardian renseigné.

0.20.0.2 — 2026-07-20

Ajouts

  • Preuve d'acceptation des conditions à l'inscription sur invitation (users.terms_accepted_at) : la case « J'accepte les conditions d'utilisation » était validée côté serveur puis jetée — aucune trace de l'acceptation n'était conservée, la rendant inopposable (art. 7 RGPD). L'horodatage est désormais persisté sur les 3 parcours de création de compte (employé, membre lié, nouveau membre) ; laissé null pour les employés, pour qui la case n'est pas affichée. Aucun backfill des comptes existants : leur consentement n'a jamais été recueilli de façon prouvable, un backfill fabriquerait une fausse preuve.

Corrections

  • Logs d'audit d'impersonation en UUID plutôt qu'en emails : admin_email/user_email ne sont plus écrits dans les logs start/stop (ImpersonationService), qui partent en prod vers syslog Clever Cloud et Laravel Nightwatch. admin_id/user_id/tenant_id suffisent à la traçabilité ; IP et user-agent restent journalisés.
  • Suppression de Gravatar (fuite d'email vers un tiers non déclaré) : l'email de l'utilisateur partait en clair dans l'URL Gravatar vers Automattic (États-Unis) à chaque affichage du header, sans figurer au registre des sous-traitants. L'avatar ne se résolvait de toute façon jamais (URL construite sans hash MD5/SHA-256) — le fallback initiales, déjà le rendu effectif, devient le rendu unique. gravatar.com retiré de la CSP img-src.
  • Documentation de SESSION_SECURE_COOKIE : la variable était absente de .env.example, exposant au risque qu'un déploiement prod tourne sans le flag Secure sur le cookie de session (atténué par HSTS, mais à fermer proprement). Ajoutée à .env.example et à Docs/Deployment/Environment.md. Action de suivi en production : clever env set SESSION_SECURE_COOKIE true.

0.20.0.1 — 2026-07-20

Corrections

  • Contention CPU sur le scaler nano Clever Cloud : le cron de scheduling ne boote plus Laravel toutes les minutes mais toutes les heures pile (0 * * * *), suite à l'alerte Nightwatch sur des pics de latence GET/HEAD / (24 boots/jour au lieu de 1440, soit 60x moins). L'horaire a été préféré à des heures fixes calées sur les tâches planifiées car le démon cron de Clever Cloud n'a pas de timezone épinglée côté infra (contrairement aux jobs Laravel, tous en Europe/Paris) — des heures fixes auraient silencieusement raté des tâches selon la timezone du démon, et l'ensemble cassé aurait changé à chaque bascule DST.
  • Synchronisation package.json avec VERSION (dérive pré-existante depuis la v0.20.0.0).

0.20.0.0 — 2026-07-20

Ajouts

  • Content-Security-Policy (CSP) enforcing sur toute l'application (SecurityHeaders middleware) : blocage effectif (plus seulement observation) des scripts non autorisés, avec un nonce unique par requête pour les pages tenant/publiques et une policy adaptée au panel admin (Livewire/Alpine). Réduit fortement l'impact d'une éventuelle faille XSS — un script injecté sans le bon nonce ne s'exécute plus. En-têtes X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy et Strict-Transport-Security (HTTPS) ajoutés à toutes les réponses.
  • Remontée des violations CSP (POST /csp-report) : le navigateur signale au serveur toute ressource bloquée par la policy, journalisée de façon bornée (4 champs whitelistés, sans le payload brut) pour surveiller les faux positifs après déploiement sans risque de fuite de données dans les logs.
  • Documentation : Content-Security-Policy & en-têtes HTTP.

0.19.4.0 — 2026-07-17

Ajouts

  • Éditeur WYSIWYG pour le compte-rendu de réunion en brouillon (MeetingReportEditor.vue, Tiptap v3) : remplace le <Textarea> markdown brut par un éditeur riche (titres, listes, tableaux, citations, code, images, liens) tout en conservant content en markdown en base — aucun changement de schéma. Le PDF et l'e-mail du compte-rendu stylent désormais tableaux, citations et blocs de code au même format.

Corrections

  • Préservation des images markdown dans l'éditeur WYSIWYG du CR (round-trip édition ↔ sauvegarde).
  • Liens javascript: neutralisés dans le rendu markdown du PDF du CR (allow_unsafe_links: false, alignement avec l'e-mail).
  • Taille maximale du contenu du compte-rendu (100 000 caractères) désormais appliquée côté serveur.

0.19.3.0 — 2026-07-15

Ajouts

  • Affichage de l'ordre du jour sur la fiche réunion (Show.vue) : chaque point de l'ordre du jour est désormais rendu (badge Traité/En attente, décision si renseignée, actions avec responsable résolu — utilisateur lié ou nom libre, échéance formatée). Auparavant la Card titrée « Ordre du jour » affichait en réalité meeting.description (mislabel) ; cette section est renommée « Notes ». Le contrôleur charge désormais agendaItems.actions.responsible en eager-load, et MeetingAgendaItem expose status/status_label en attributs calculés.
  • Compte-rendu de réunion généré par IA (Mistral) : à la clôture, le CR est désormais généré en arrière-plan par GenerateMeetingReportJob — synthèse IA (MeetingReportSynthesizer) en chemin nominal, secours automatique sur le template déterministe existant en cas d'échec (timeout, erreur API), sans jamais bloquer ni faire échouer la clôture elle-même. La clôture (close()) devient elle-même atomique et idempotente (garde status != completed), tout comme la nouvelle action d'annulation d'une séance en cours (cancelLive(), POST /meetings/{id}/cancel-live) qui permet de revenir de live à scheduled en cas d'erreur de manipulation.
  • Page de conduite en direct repensée (Live.vue) : navigation par onglets (Ordre du jour / Notes / Transcription), notes de séance libres autosauvées (PATCH /meetings/{id}/notes) remplaçant l'ancienne saisie décision/action point par point, et chronomètre de séance qui survit désormais à un rechargement de page (started_at persisté).
  • Champs lieu distant et téléphone sur les réunions (meeting_link, phone) : une réunion peut désormais porter un lien de visioconférence et/ou un numéro d'appel, affichés sur la fiche et dans le formulaire.
  • Garde-fou séance bloquée : une commande planifiée quotidienne (meetings:notify-stuck-live, 08:00 Europe/Paris) détecte les réunions restées live plus de 2h après leur ends_at et notifie l'organisateur par email (MeetingStuckLiveMail) — notification uniquement, aucune mutation automatique de statut ou de données.

0.19.2.0 — 2026-07-15

Modifications

  • Simplification de l'ordre du jour des réunions : les points de l'ordre du jour perdent la durée estimée, le responsable dédié et les horodatages de démarrage/clôture (estimated_duration_minutes, responsible_user_id, started_at, ended_at), remplacés par un champ description libre. La progression pendant la conduite en direct (pending/actif/terminé) est désormais suivie côté client, sans persistance par point.

Corrections

  • Garde de transition Draft → Live : l'ouverture de la page Live (GET /meetings/{id}/live) ne transitionne plus que les réunions scheduled vers live ; une réunion draft ouverte directement en Live reste draft au lieu d'être basculée à tort.

0.19.1.0 — 2026-07-06

Modifications

  • Découpage du contrôleur des inscriptions par ressource HTTP : le RegistrationController monolithique (2 170 lignes, 27 actions) est scindé en 6 contrôleurs dédiés — CRUD inscriptions, transitions de statut (valider/refuser/annuler), gestion de cours (ajout/retrait/échange + aperçus), panier (détail, paiement, facture PDF, membres, notes), relances et export CSV. Aucun changement de comportement : URLs, noms de routes et autorisations strictement identiques (déplacements verbatim vérifiés mécaniquement).
  • Les aides partagées (filtres de liste, représentant de panier, options de campagne, noms de cours) deviennent des traits réutilisables Concerns/, et la liste des raisons comptant comme « relance manuelle » est centralisée sur l'énum RelanceReason::MANUAL_REASONS (valeurs inchangées).

Ajouts

  • Test unitaire de l'énum RelanceReason : libellés et contenu exact de MANUAL_REASONS désormais verrouillés.

0.19.0.1 — 2026-07-03

Corrections

  • Mail « Paiement reçu » reflète le solde du panier, pas la ventilation par inscription : PaymentReceivedMail interrogeait le solde de la seule inscription réglée, qui peut diverger du solde réel du panier après une re-ventilation des paiements. Le mail agrège désormais toutes les inscriptions non terminales du panier et affiche le solde VersementService::cartOutstandingCents — élimine les mails annonçant un reste à payer alors que le panier est soldé.

0.19.0.0 — 2026-07-03

Ajouts

  • Lien de paiement en ligne pour panier offline impayé : depuis le détail panier, un bouton du panneau de relance génère un lien de paiement HelloAsso pour un panier initialement réglé hors ligne (chèque, virement, espèces) qui reste impayé — sans obliger l'adhérent à repasser par tout le formulaire. Guardé par token public valide, solde panier > 0 relu sous verrou, et HelloAsso configuré pour le tenant (le bouton est masqué sinon).
  • Verrou de checkout HelloAsso anti double-clic/double-onglet : Cache::lock par panier (30s, attente 5s) sérialise les checkouts concurrents sur le même jeu d'inscriptions ; le solde est relu sous verrou juste avant chaque appel HelloAsso, avec dégradation gracieuse (HelloAssoAlreadySettledException) si un règlement concurrent a déjà tout soldé. Les appels HTTP HelloAsso sont bornés à 10s pour ne jamais dépasser la durée du verrou.

Corrections

  • Le montant réclamé par la relance et le checkout HelloAsso se base désormais sur le solde du panier (VersementService::cartOutstandingCents), plus sur la ventilation par inscription — élimine les relances erronées après une re-ventilation des paiements à l'annulation.
  • Élimination de plusieurs N+1 (registration.payments, registration.balance) dans HelloAssoRelanceService et le flux de retry HelloAsso.
  • Exclusion des paiements HelloAsso fantômes de la relance panier : payableCartPayments() (et canSendManualRelance(), createOnlinePaymentLink()) retournent vide dès que le panier n'a plus de solde dû au niveau versement (VersementService::cartOutstandingCents), même si un Payment Pending/Rejected résiduel survit sur une inscription réglée hors ligne entre-temps ; garde sur destinataire absent ; resynchronisation de Payment.amount au moment du checkout.