Dev #4
Assignees
w-vandal (Vandal William)
Clear assignees
w-vandal (Vandal William)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Forge-Store/Forge-Engine#4
Reference in New Issue
Block a user
Bug rapporté : poser un élément de jeu ("Mes éléments de jeu") dont le modèle n'est qu'une "Superposition / boîte de dialogue" sur une vraie scène affichait un conteneur vide à l'endroit du dépôt — jamais le dialogue. La boîte de dialogue existait bien (masquée comme prévu, en attente d'une action qui l'affiche) : c'est l'enveloppe qui l'entoure qui n'aurait jamais dû être visible. Cause : tout exemplaire d'élément de jeu est posé avec le widget générique "conteneur" par défaut (add_element.py, colonne default_widget) — son contenu réel (le modèle) est rechargé EN DIRECT à l'intérieur (_render_element_type_children), mais l'enveloppe "conteneur" elle-même reste une boîte NORMALE, toujours visible, avec sa propre couleur de fond/ bordure et sa position fixe sur le canevas (contrairement à une superposition posée directement, qui, elle, démarre masquée). Résultat : une boîte vide et permanente à l'endroit du dépôt, pendant que le vrai dialogue (démarré masqué, correctement) reste invisible en dessous/ au-dessus tant qu'aucune action ne le déclenche. Correctif : quand le modèle ENTIER d'un élément de jeu n'est qu'une seule superposition (screens/element_types/is_overlay_only.py, nouveau), on court-circuite entièrement l'enveloppe "conteneur" (render_element_html.py) et on retire aussi le z-index de son cadre de positionnement (element_style_filter.py, list_elements.py) — même raison que pour une superposition posée directement (81c31a9) : sans ça, ce cadre reste un candidat à piéger le z-index:9999 du dialogue rendu à l'intérieur dès qu'un autre élément de la scène a un z-index plus grand. Nouveau test, confirmé en échec sur l'ancien code (même "class=\"box\"" fantôme reproduit) puis au vert avec le correctif. 140 tests au vert au total. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>Deux fonctionnalités demandées, développées et corrigées dans cet échange : 1. "Donnée liée" (Texte/Titre) : le réglage à 2 filtres fixes (toujours combinés en ET) devient une liste de conditions ILLIMITÉE, avec un choix ET/OU pour les combiner (screens/widgets/controls/c_clause_list.py, screens/clause_list_codec.py). Rétrocompatible avec les anciens éléments (_data_filtre_champ/_data_filtre2_champ), convertis à la volée à la lecture, sans migration. Après un premier essai à la présentation trop compacte et technique (retour utilisateur : "pas de champ technique, pas de notation bizarre {{ }}"), la présentation finale reprend EXACTEMENT l'ancien style (labels "Champ"/"...est"/ "...cette valeur", même sélecteur de valeur fixe/dynamique/variable déjà existant, jamais la syntaxe brute), simplement répétée par condition (templates/partials/clause_row.html), avec un bouton "+ Ajouter une condition" bien visible et une liste scrollable (static/style.css, .clauseListWrap). Le même moteur (filter_repeater_ rows.py généralisé) profite aussi au Répéteur de données en interne. 2. Nœud Condition de la Logique de la scène : peut désormais tester une VARIABLE GLOBALE en plus d'un champ d'objet (cond_source/cond_variable/ cond_variable_chemin — screens/flow/ensure_flow_schema.py), sur la clause principale ET chaque clause supplémentaire (ET/OU). Évalué côté CLIENT (templates/play.html, evaluateConditionClause), contre un nouveau gameData.variables exposé par full_game_payload.py — tenu à jour par refreshRuntimeData() après toute action qui modifie une variable, sans changement supplémentaire nécessaire. Le panneau de condition reste utilisable même sans aucun objet défini dans le jeu (avant, il disparaissait entièrement). Vérifié : 153 tests pytest (nouveaux : test_data_binding_clause_list.py, test_condition_variable.py) + logique JS d'évaluation des conditions vérifiée isolément avec Node (variable scalaire, objet avec chemin chaîné, tableau par index, variable introuvable, booléen, rétrocompatibilité legacy) + rendu des deux pages (éditeur/jeu) vérifié sur le vrai projet "test" en plus des jeux de test. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>Deux bugs cumulés dans auth/totp_qrcode_svg.py : - SvgImage (variante utilisée) ne pose aucun attribut viewBox sur le <svg> racine — la règle CSS qui le fait tenir dans son cadre (.totpQrWrap svg { width:100% }) n'avait donc rien à quoi se raccorder pour mettre à l'échelle le dessin interne (coordonnées en mm) : le QR code restait invisible/coupé. Remplacé par SvgPathImage, seule variante pure Python de qrcode dont le <svg> racine inclut un viewBox. - qrcode.make() préfixe toujours sa sortie d'une déclaration XML ("<?xml version=...?>"), valide pour un fichier .svg autonome mais invalide au milieu d'un document HTML — ne garder que ce qui commence à "<svg" avant de l'insérer dans la page. 165 tests toujours au vert. Le compte non confirmé resté bloqué sur cet écran (vandal.william@forgebase.fr) a été supprimé de data/users.db : la prochaine inscription redevient bien le tout premier compte (admin). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>10 codes à usage unique (format "xxxx-xxxx-xxxx") sont générés à l'instant même où la 2FA est confirmée (auth/recovery_codes.py, table _recovery_codes séparée pour marquer/consommer chaque code un par un) — seul leur hash (werkzeug, comme les mots de passe) est stocké, ils ne sont visibles en clair qu'à cet instant précis. Plutôt que d'interrompre la redirection habituelle après confirmation de la 2FA, les codes sont posés en session ("recovery_codes_to_show") et affichés une seule fois, en modal, dès le premier rendu de base.html qui suit (core/recovery_codes_flash.py, session.pop) — préserve tel quel le comportement de redirection déjà couvert par les tests existants. Sur /login/2fa, un code de récupération est accepté à la place du code TOTP habituel (routes/auth/login_2fa.py) : verify_totp est essayé en premier (verify_recovery_code consomme le code dès qu'il correspond, on ne veut pas en griller un pour rien sur une saisie qui aurait en fait été un TOTP valide). Compte toujours vers le même compteur anti-bruteforce que le code TOTP (déjà en place, voir auth/rate_limit.py). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>