Projet

Général

Profil

Bug #31931

Remplacement de certains commentaires dans les formulaires par leur version html brut

Ajouté par Victor Claudet il y a presque 5 ans. Mis à jour il y a presque 5 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
-
Version cible:
-
Début:
02 avril 2019
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:

Description

Constaté sur cd14 il y a quelques jours en prod et maintenant sur la prod toulouse.

J'ai dupliqué un des formulaires avant correction pour que quelqu'un puisse regardé : https://demarches-montoulouse.eservices.toulouse-metropole.fr/backoffice/forms/38/

certains champs commentaires comportant du html et:ou des conditions se retrouvent tout à coup affiché sans l'encodage html (visibilité des balises et des conditions)

Je poste sur w.c.s parce que je pense plutôt à un problème général à vérifier sans doute sur d'autres plateformes de prod.


Fichiers

t2.py (870 octets) t2.py Frédéric Péters, 08 avril 2019 15:21

Historique

#1

Mis à jour par Victor Claudet il y a presque 5 ans

bon et dans le cas du cd14 j'ai eu aucun mal à revenir à la normal, copie du html et recopie en mode source puis validation. Pour Toulouse j'ai à nouveau l'affichage des balise et condition après validation.

#2

Mis à jour par Victor Claudet il y a presque 5 ans

ça semble se résoudre en ajoutant une balise ouvrante et un fermante en début et fin du source "div". (et en ajustant la mise en forme qui a un peu explosée)

#3

Mis à jour par Frédéric Péters il y a presque 5 ans

  • Statut changé de Nouveau à Fermé

ça semble se résoudre en ajoutant une balise ouvrante et un fermante en début et fin du source "div". (et en ajustant la mise en forme qui a un peu explosée)

Ça fait pourtant très longtemps que pour marquer l'HTML il faut une balise au début; à voir l'exemple Toulouse (commentaire qui fait {% if ... %}<p>...) je me dis qu'une différence est que précédemment l'analyse se faisait après avoir fait l'évaluation du gabarit.

Il n'y aura de toute façon pas de changement côté w.c.s. (la situation actuelle est plus sûre et on n'a pas de méthode garantie pour détecter la situation); j'ai ajouté un lien vers ce ticket dans le pad côté réunion CPF.

#4

Mis à jour par Frédéric Péters il y a presque 5 ans

Papotant tout seul sur le salon, j'écrivais :

bon, pour revenir sur cette histoire de balisage visible dans les champs commentaire
le fonctionnement précédent était de considérer que c'était de l'html s'il y avait un < au début.
il se fait qu'il y avait un bug, qui faisait que ce n'était pas nécessaire
genre on pouvait écrire
les trucs avec une <strong>étoile</strong> sont obligatoires.
et ça passait, par erreur.
en se combinant avec l'autre truc, qui était qu'une ligne blanche était interprétée comme une séparation en paragraphes.
bref, comme ça passait avant, ça a été pratiqué (avant que le ckeditor ne soit utilisé, ce qui a arrêté ces erreurs)

Et là, je suis passé sur le SaaS recette et prod, pour corriger au mieux les choses.

Formats disponibles : Atom PDF