Project

General

Profile

Bug #46694

Erreur de rendu, gabarit apparemment manquant ('NoneType' object has no attribute 'get_exception_info')

Added by Paul Marillonnet 4 months ago. Updated 4 months ago.

Status:
Rejeté
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
16 Sep 2020
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:
No

Description

Sur https://demarches-sguiet.test.entrouvert.org/backoffice/data/ -> Fiche "Catalogue Tags" -> "Internal Server Error"


Files

History

#2

Updated by Paul Marillonnet 4 months ago

Je pense que c'est ça. Je vais tester.

#3

Updated by Paul Marillonnet 4 months ago

Je ne reproduis pas, même après import du formulaire, du wf et du modèle de fiche (depuis l'instance posant problème), et déroulement d'une ou deux démarches de signalement qui mènent à la création de fiches.
Étrange cette affaire.

#4

Updated by Paul Marillonnet 4 months ago

Désactiver l'affichage du champ dans les tableaux de résumé met fin à ce plantage (le tableau mentionné dans la description est maintenant accessible).

#5

Updated by Frédéric Péters 4 months ago

Vraiment pas partant pour taper ça, surtout sans possibilité de
reproduire; il faudrait alors creuser l'origine de widget-control, qui
doit exister pour une raison, etc. trop de risques sans ça de casser un
usage.

#6

Updated by Paul Marillonnet 4 months ago

  • Status changed from Solution proposée to En cours

Frédéric Péters a écrit :

Vraiment pas partant pour taper ça, surtout sans possibilité de
reproduire; il faudrait alors creuser l'origine de widget-control, qui
doit exister pour une raison, etc. trop de risques sans ça de casser un
usage.

Sûr. Pas question de taper ça sans pouvoir reproduire.

#7

Updated by Paul Marillonnet 4 months ago

Et, pour tout dire, je creuse cette piste parce que la docstring de render_widget_content affirme que ça rend le

 widget content (without label, hint, etc.)
tout en utilisant le bloc widget-content, alors que dans le gabarit de base de rendu de widget (étendu par le gabarit de rendu de champ carte, lequel surcharge le bloc widget-control) le bloc widget-content contient ces informations prétendument exclues :
  {% block widget-content %}
  <div class="content {{widget.content.content_extra_css_class}}" 
       aria-labelledby="form_label_{{widget.name}}" 
     {% for attr, value in widget.content_extra_attributes.items %}
     {{attr}}="{{value}}" 
     {% endfor %}
       >
    {% block widget-error %}{{widget.rendered_error}}{% endblock %}
    {% block widget-control %}{{widget.render_content|safe}}{% endblock %}
    {% block widget-hint %}{{widget.rendered_hint}}{% endblock %}
  </div>
  {% endblock %}

#8

Updated by Frédéric Péters 4 months ago

Pour reprendre, le tableau de traitement mais aussi une demande particulière https://demarches-sguiet.test.entrouvert.org/backoffice/data/catalogue-des-tags/5/ , mais aussi la vue inspect de celle-ci, https://demarches-sguiet.test.entrouvert.org/backoffice/data/catalogue-des-tags/5/inspect, avec cette trace :

Exception:
  type = '<class 'KeyError'>', value = ''form_var_lieu_lat''

Stack trace (most recent call first):
  File "/usr/lib/python3/dist-packages/wcs/qommon/substitution.py", line 214, in __getitem__
   212                         # TypeError will happen if indexing is used on a string
   213                         if i == 1:
>  214                             raise KeyError(key)
   215                     else:
   216                         parts = parts[i:]

  locals:
     __class__ = <class 'wcs.qommon.substitution.CompatibilityNamesDict'>
     current_dict = <wcs.variables.LazyFieldVarMap object at 0x7f37c0579b70>
     i = 1
     key = 'form_var_lieu_lat'
     part = 'lat'
     parts = ['lat']
     self = {'form': <wcs.variables.LazyFormData object at 0x7f37c05e2a58>, 'attachments': <wcs.workflows.AttachmentsSubstitutionProxy object at
0x7f37c05e2e80>}

Si on regarde la demande,

>>> carddef = CardDef.get(8)
>>> carddata = carddef.data_class().get(5)
>>> [x for x in carddef.fields]
[<MapField 1 'Lieu'>, <ItemField 2 'Intérêt'>]
>>> carddata.data
{'1': 'form_var_lieu', '2': 'form_var_interet', '2_display': 'form_var_interet'}

Et de là mon idée est que les fiches ont été créées en important un CSV et que ça autorise n'importe quoi à aller dans un champ carte.

>>> for carddata in carddef.data_class().select():
...     if carddata.data['1'] and 'form_var' in carddata.data['1']:
...         carddata.data['1'] = ''
...         carddata.store()
... 

Et voilà.

Il faudrait vérifier avec Stéphane la manière dont les fiches ont été créées.

Inutile par contre d'essayer d'empêcher le bug, il y a #46617 qui vient changer le stockage pour les champs carte.

#9

Updated by Paul Marillonnet 4 months ago

  • Status changed from En cours to Rejeté

Frédéric Péters a écrit :

Pour reprendre, le tableau de traitement mais aussi une demande particulière https://demarches-sguiet.test.entrouvert.org/backoffice/data/catalogue-des-tags/5/ , mais aussi la vue inspect de celle-ci, https://demarches-sguiet.test.entrouvert.org/backoffice/data/catalogue-des-tags/5/inspect, avec cette trace :

[...]

Si on regarde la demande,

[...]

Et de là mon idée est que les fiches ont été créées en important un CSV et que ça autorise n'importe quoi à aller dans un champ carte.

[...]

Et voilà.

Il faudrait vérifier avec Stéphane la manière dont les fiches ont été créées.

Inutile par contre d'essayer d'empêcher le bug, il y a #46617 qui vient changer le stockage pour les champs carte.

Ok, merci pour le fin mot de l'histoire. Je rejette le ticket.

Also available in: Atom PDF