Erreur provoquée par le champ "description"

[eprouteau]

Bonjour,

Je suis entrain de préparer l'import de mes 900 itinéraires sur mon instance et je bloque sur le champ description. Si j'ajoute une description via SQL ou Qgis direct en base dans trekking_trek, celle-ci est bien visible dans l'admin mais provoque une erreur sur geotrek-Rando. pour corriger l'erreur, ,il faut que j'ouvre la rando dans l'admin geotrek et que je fasse sauvegarder.

Y a t-il un mécanisme particulier sur ce champ quand on passe via l'interface admin ?

Erreur : https://randordogne.viree-outdoor.com/trek/1396-test-desc

De même, les modifs de description faites directs en base ne sont pas bien prises en compte.

Bonne journée,

[camillemonchicourt]

Je ne vois pas de raison, c'est un champs texte HTML comme d'autres. Peux-tu donner un exemple du contenu du champs avant et après modification pour voir si il est différent ?

Peut-être le faire que les caractères spéciaux sont encodés en HTML quand on passe par l'éditeur de Geotrek-admin ?

[camillemonchicourt]

Faudrait aussi les logs d'erreur de Geotrek-rando quand on ouvre une fiche qui pose soucis.

[eprouteau]

logs node :

J'ai testé avec une valeur sans accent saisie dans description et description_fr. pas de changements après la sauvegarde via le front. tout les champs en valeur par défaut '' le sont bien.

[eprouteau]

Autre test, valeurs saisie en base sur un itinéraire existant sans description bien présent dans l'admin mais inexistant sur le front. c'est comme si de passer par l'admin synchronisait quelque chose.

[eprouteau]

J'ai re bien défini dans qgis que tous les champs devait être en valeur '' et cela semble ok. Il doit y avoir un combo de champ et si l'un est en valeur null ca pose problème. Je valide ca à plus grande échelle.

[camillemonchicourt]

Oui aucun champs vide ne doit être à NULL, mais à ''. C'est normalement aussi géré par les valeurs par défaut de la BDD. Si il en manque c'est à noter et compléter pour ne pas avoir à passer par l'admin.

[marcantoinedupre]

Quelques remarques sur ce point, peut-être que ça peut aider.

champs de traduction nullables et sans default value

Les champs de traduction (par exemple description_fr ou ambiance_en) sont toujours en nullable sans la valeur texte vide par défaut. C'est dû à leur aspect dynamique (dépendant de la configuration de l'instance) et à la bibliothèque logicielle django-modeltranslation qui s'attend à gérer les valeurs vides dans l'applicatif. De ce fait il faut faire attention pour les imports ou les insertions directement en BD. Je conseillerais de systématiquement définir les valeurs (un texte ou '') pour tous ces champs.

Comportement de geotrek-rando avec les valeurs vides/nulles de l'API

geotrek-rando gère parfois les valeurs nulles. Ça dépend des champs. Ce n'est pas uniforme car c'est un palliatif pour une correction qu'on préfèrerait avoir dans l'API de geotrek-admin. Bref ça a été mis en place au cas par cas.

[eprouteau]

Les champs de traduction (par exemple description_fr ou ambiance_en) sont toujours en nullable sans la valeur texte vide par défaut. C'est dû à leur aspect dynamique (dépendant de la configuration de l'instance) et à la bibliothèque logicielle django-modeltranslation qui s'attend à gérer les valeurs vides dans l'applicatif. De ce fait il faut faire attention pour les imports ou les insertions directement en BD. Je conseillerai de systématiquement définir les valeurs (un texte ou '') pour tous ces champs.

Du coup c'est ce que je fais je met un '' pour l'ensemble des champs et c'est passé.

[camillemonchicourt]

OK pour moi un champs non obligatoire devrait pour avoir comme valeur NULL. Cela de manière globale au niveau de Geotrek-admin, mais aussi de Geotrek-rando (ou cela devrait être géré globalement et non pas champs par champs justement pour éviter l'hétérogénéité).

[marcantoinedupre]

OK pour moi un champs non obligatoire devrait pour avoir comme valeur NULL.

La convention Django pousse plutôt pour la valeur texte vide pour les champs textes (voir la doc Django).

Ce n'est qu'une convention. De toutes les manières le but est d'arriver à ce qu'il n'y ait pas des données avec plusieurs possibilités pour la valeur vide. Afin d'éviter des if is_undefined(value) or is_null(value) or is_empty(value) un peu partout dans le code.

Pragmatiquement le choix serait basé sur un mix :

• des conventions usuelles,
• de l'état de la code base,
• et du moindre effort au niveau des conversions et tests nécessaires (par exemple les formulaires HTML renvoient des '' pour les textes vides, il faudrait que toutes les vues Django les convertissent en None pour avoir NULL en BD).