Bug #59756
libellé de champ "True" considéré comme un booléen lors d'un import
0%
Description
Et plouf évidemment personne ne s'attend à ça.
Exception:
type = '<class 'TypeError'>', value = 'expected string or bytes-like object'
Stack trace (most recent call first):
File "/usr/lib/python3.7/re.py", line 192, in sub
190 a callable, it's passed the Match object and must return
191 a replacement string to be used."""
> 192 return _compile(pattern, flags).sub(repl, string, count)
193
194 def subn(pattern, repl, string, count=0, flags=0):
locals:
count = 0
flags = 0
pattern = '<.*?>'
repl = ' '
string = True
File "/usr/lib/python3/dist-packages/wcs/fields.py", line 296, in unhtmled_label
294 @property
295 def unhtmled_label(self):
> 296 return force_str(html.unescape(force_text(re.sub('<.*?>', ' ', self.label or ''))).strip())
297
298 @property
locals:
self = <ERROR WHILE PRINTING VALUE>
Fichiers
Révisions associées
Historique
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Fichier 0001-fields-add-explicit-typing-of-some-attributes-in-exp.patch 0001-fields-add-explicit-typing-of-some-attributes-in-exp.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Deux bouts :
- 1/ une liste TEXT_ATTRIBUTES qui liste explicitement des attributs devant être traités comme du texte, ça assure que les export actuels, même s'ils ont "True" en libellé, fonctionnent.
- 2/ l'ajout d'un attribut aux nœuds pour renseigner le type (bool, int, str), ça permet l'exhaustivité que le 1/ n'offre pas.
Mis à jour par Thomas Noël il y a plus de 2 ans
Par symétrie avec la gestion des booléens, au lieu de :
elif elem_type == 'int' or isinstance(getattr(self, attribute), int):
ne gérer le second cas que si elem_type est None (ie si on est sûr que ce n'est pas un texte) :
elif elem_type == 'int' or (not elem_type and isinstance(getattr(self, attribute), int)):
Non ?... (je pense que ça ne peut pas arriver, d'avoir un nombre dans les varname & co, mais bon, hein)
[ A noter quand même qu'avec un XML forgé avec des mauvais types, on pourrait se faire un peu "casser" ? Ok, c'est un angle d'attaque tout foireux, et si ça fini en 500 y'a pas de drame, mais j'aime bien poser des questions ]
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Fichier 0001-fields-add-explicit-typing-of-some-attributes-in-exp.patch 0001-fields-add-explicit-typing-of-some-attributes-in-exp.patch ajouté
Non ?... (je pense que ça ne peut pas arriver, d'avoir un nombre dans les varname & co, mais bon, hein)
Non mais voilà.
[ A noter quand même qu'avec un XML forgé avec des mauvais types, on pourrait se faire un peu "casser" ? Ok, c'est un angle d'attaque tout foireux, et si ça fini en 500 y'a pas de drame, mais j'aime bien poser des questions ]
Pas de drame.
Mis à jour par Thomas Noël il y a plus de 2 ans
- Statut changé de Solution proposée à Solution validée
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 22e2b581233ad6b836e1dbfb35a7c20e2d85176d
Author: Frédéric Péters <fpeters@entrouvert.com>
Date: Wed Dec 15 17:46:14 2021 +0100
fields: add explicit typing of (some) attributes in export/import (#59756)
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Statut changé de Résolu (à déployer) à Solution déployée
fields: add explicit typing of (some) attributes in export/import (#59756)