Impossible d'utiliser une nomenclature dynamique

[dece]

Bonjour, j'essaye de paramétrer un groupe de site pour avoir différents paramètres d'habitats, organisés en plusieurs niveaux. Il faudrait par exemple que le type de nomenclature du niveau 2 puisse être dynamiquement modifié en fonction de la sélection de l'utilisatrice pour le niveau 1. Lorsque j'essaye de configurer un paramètre dynamique — ici pour habitat_main_2 avec une fonction bidon mais qui rendrait idéalement une valeur en fonction de la valeur de habitat_main_1 — j'ai l'erreur suivante.

Nomenclature :

"habitat_main_1": {
  "type_widget": "nomenclature",
  "attribut_label": "Habitat principal (niveau 1)",
  "code_nomenclature_type": "STERF_HAB_N1",
  "required": true,
  "type_util": "nomenclature"
},
"habitat_main_2": {
  "type_widget": "nomenclature",
  "attribut_label": "Habitat principal (niveau 2)",
  "code_nomenclature_type": "({value}) => 'STERF_HAB_N2'",
  "required": true,
  "type_util": "nomenclature"
},

Erreur :

Traceback (most recent call last):
  File "/home/geonatureadmin/geonature/backend/venv/lib/python3.11/site-packages/flask/app.py", line 917, in full_dispatch_request
    rv = self.dispatch_request()
         ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/geonatureadmin/geonature/backend/venv/lib/python3.11/site-packages/flask/app.py", line 902, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/geonatureadmin/geonature/backend/dependencies/Utils-Flask-SQLAlchemy/src/utils_flask_sqla/response.py", line 19, in _json_resp
    res = fn(*args, **kwargs)
          ^^^^^^^^^^^^^^^^^^^
  File "/home/geonatureadmin/modules/gn_module_monitoring/backend/gn_module_monitoring/routes/data_utils.py", line 91, in get_init_data
    for nomenclature in nomenclature_list["values"]:
                        ~~~~~~~~~~~~~~~~~^^^^^^^^^^
TypeError: 'NoneType' object is not subscriptable

Dois-je en conclure que ça n'est pas possible d'avoir une nomenclature dynamique ?

Je suis ouvert aux suggestions pour implémenter ça autrement, j'avais pensé à essayer de tout mettre dans une seule nomenclature et filtrer les choix du select avec un paramètre dynamique, sans succès ( comme dans #504 ). J'ai également essayé de définir mon paramètre en datalist et rendre dynamique le paramètre "api" pour faire la nomenclature à fetch dynamiquement, mais même erreur.

Geonature v2.15.4 et module monitoring 1.0.3.

[camillemonchicourt]

Je pense qu'il y a différents sous-modules de Monitoring qui utilisent des champs conditionnels, avec des liens entre les valeurs de formulaires, mais je ne sais pas lesquels ni comment faire. Donc je ne peux pas aider de mon côté.

[dece]

C'est possible de filtrer dynamiquement les options d'un champ de type select en fonction de la valeur choisie sur un autre champ, ça sera ma solution si jamais je m'en sors pas avec les nomenclatures. Par contre pour les champs de type nomenclature ou datalist, je ne trouve pas. J'ai cloné le dépôt avec tous les protocoles de suivis pour chercher s'il y a une astuce dans l'un d'eux avec filters ou params mais rien trouvé non plus.

[dece]

Par manque de temps j'ai fait autrement, je partage ma solution si jamais d'autres personnes se retrouvent dans le même cas de figure.

Pour être prévoyant et préparer d'éventuels changements du module qui permettraient d'avoir des nomenclatures dynamiques, j'ai quand même créé les quatres nomenclatures (une par niveau), et ensuite j'ai créé les paramètres pour les 4 niveaux de la sorte :

• habitat_main_1 : type nomenclature (STERF_HAB_N1)
• habitat_main_2 : type select
• habitat_main_3 : type select
• habitat_main_4 : type select

Les niveaux 2 à 4 ont quand même leur propre nomenclature (STERF_HAB_N2, …).

Le select de niveau 2 a un paramètre values dynamique pour se baser sur la valeur du niveau 1. En utilisant le code suivant, on va pouvoir remplir le select avec les labels de la nomenclature de niveau 2 (ici en se basant sur les premières lettres des cd_nomenclatures). C'est pas ouf parce que bon on stock des labels au lieu des codes de nomenclature donc ça casse si le label est modifié, mais en attendant ça me permet lors de l'export SQL de retrouver mes nomenclatures.

({value, meta}) => {
  const level1 = meta.nomenclatures[value.habitat_main_1];
  if (level1 === undefined)
    return [];
  const filterNomenclatures = (startsWith) =>
    Object.values(meta.nomenclatures).filter(n => n.cd_nomenclature.startsWith(startsWith));
  const mapToLabels = (nomenclatures) =>
    nomenclatures.map(n => n.label_default);
  switch (level1.cd_nomenclature) {
    case 'HAB1_A':
    case 'HAB1_B':
      return mapToLabels(filterNomenclatures('HAB2_AB_'));
    // …
  }
  return []
}

Si on essaye d'utiliser ce code de cette façon, ça ne fonctionne pas car aucune propriété de l'entité n'utilise les nomenclatures de niveaux 2 à 4, donc elles ne sont pas disponibles dans l'objet meta.nomenclatures. L'astuce c'est d'ajouter des propriétés "invisibles" pour les charger, par exemple pour le niveau 2 :

"habitat_nomenclature_2": {
  "type_widget": "nomenclature",
  "attribut_label": "Nomenclature d'habitat Sterf (niveau 2) [interne]",
  "code_nomenclature_type": "STERF_HAB_N2",
  "required": false,
  "hidden": true,
  "type_util": "nomenclature"
},

Du coup ça fera l'affaire pour une première version du module, mais je suis intéressé par cette feature pour pouvoir simplifier tout ça plus tard :)

[camillemonchicourt]

Merci pour ce retour.
A voir donc comment cela peut être amélioré.

[ahurabielle]

J'ai eu le même genre de cas et j'ai à chaque fois contourné ou évité l'implémentation par niveaux.
Donc effectivement, ça serait intéressant comme nouvelle fonctionnalité :)