Ajout des contrôles Backends

[christophe-ramet]

Actuellement dans Monitoring, les contrôles spécifiques à un protocole ne sont faits que dans le frontend. L'objectif est ici de faire en sorte que le frontend et le backend partage une définition commune des contrôles (au moins en partie).

• Faire une analyse technique ;
• Faire un choix de mise en œuvre ;
• Expliciter la transition voulue (deux systèmes qui cohabitent ? Transition sèche ? Transition progressive)
• établir le backlog

[christophe-ramet]

Ci-dessous l'étude réalisée par @edelclaux

Contrôle des données dans Monitoring

• Controle des données dans Monitoring
  • Problématique
  • Syntaxe actuelle
    • Champs requis
    • Champs conditionnel
    • Champs requis ET conditionnel
    • Attribut inter-champs
    • Valeurs possible d'une liste
    • Modification du state lors de modification dans le formulaire
    • List - valeur en bdd
    • List - contrôle de nomenclatures (habitats, users, etc.)
  • Evolution de syntaxe - JSON Schema
    • Stack jsonschema
    • Compatibilité des exigences de et jsonschema
      • 1. required suivant présence d'un champs
      • 2. required suivant la valeur d'un autre champs
      • 3. list values
      • 4. interval
      • 5. Listes avec valeurs en bdd (nomenclatures, etc.)
      • 6. Listes avec valeurs en bdd (très grande liste)
        • cd_typo en paramètre enfant
        • cd_typo en paramètre du même niveau
    • Intégration de jsonschema aux protocoles monitoring
      • Aucun changement de l'existant
      • Changement de l'existant
      • specific, generic
    • Gestion des cas particuliers / nouveaux
  • Validation backend
    • Dans la route
    • Dans l'import
  • Restitution 13 aout
    • Generic EST modifiable
    • additionalProperties
    • Liste - données issues de bdd
    • Mélange avec marshmallow

Problématique

La version actuelle de monitoring ne dispose pas de vérification des données côté backend.

Les données saisies dans monitoring ne sont controlées que dans le frontend, côté formulaire. Une requête d'ajout de visite sur prairie fleuries valide peut être:

{
  "id_base_site": 1,
  "...": "...",
  "visit_date_min": "2025-8-2",
  "mecanisation_parcelle_n_1":"etienne",
  "pature_chargement_n_1": "etienne",
  "pature_fertilisation_qte_n_1": "etienne",
  "pature_fertilisation_type_n_1": "etienne",
  "pature_type_animaux_n_1": "etienne",
  "rendement_parcelle_n_1": "etienne",
  "utilisation_periode_n_1": "etienne",
  "utilisation_type_n_1": "etienne"
}

A noter qu'il y a dedans des valeurs de nomenclatures et des valeurs numériques.

Cette absence de contrôle des données en backend est un problème dans tous les cas. Il devient aujourd'hui assez critique avec la possibilité de saisir des données dans monitoring sans passer par le front du module, via le module d'import ou l'application monitoring mobile.

Un des obstacles à la mise place de la validation côté backend est l'utilisation du javascript au sein de le définition de certains attributs des protocoles.

Exemple:

  // petite_chouette_montagne > observation.json > nb_hulotte
  "hidden": "({value}) => value.hulotte != 'Oui'",
  "required": "({value}) => value.hulotte == 'Oui'",

Le champs nb_hulotte peut être caché ou requis suivant la valeur d'un autre champs, hulotte.
La relation est très logique, mais l'approche javascript ne permet pas son interprétation ailleurs que dans le formulaire du frontend.
le JS est utilisé pour mettre en place une logique interchamp (relations min max, required dynamique, etc.).

On doit faire évoluer la syntaxe des protocles pour permetter la validation backend.

On propose donc ici de traiter l'évolution de cette syntaxe, et de son traitement.

Syntaxe actuelle

La syntaxe actuelle des protocoles contient à la fois des élements de définition du formulaire (hidden, label, type_widget, description, etc.) et des élements de validation du formulaire (required, etc.).

On fera ici la distinction entre les champs de définition et de validation.

Champs requis

Un champs peut être requis ou non suivant la valeur d'un autre champs.
Le js peut être utilisé pour mettre en place cette relation.

  // petite_chouette_montagne > observation.json > nb_hulotte
  "required": "({value}) => value.hulotte == 'Oui'"

required --> validation

Champs conditionnel

La pertinence de l'existence d'un champs peut dépendre du statut d'un autre.
Le js peut être utilisé pour mettre en place cette relation.

  // guano > visit.json > guano_comment
  "hidden": "({value}) => !value.guano_presency"

hidden --> définition (comfort de saisie)

Champs requis ET conditionnel

On observe très souvent le mélange des deux précédénts.

  // petite_chouette_montagne > observation.json > chev_chant
  "hidden": "({value}) => (value.cd_nom != (null || undefined) ? value.cd_nom != 3507 : true)",
  "required": "({value}) => (value.cd_nom != (null || undefined) ? value.cd_nom == 3507 : false)"

hidden --> définition
required --> validation

Attribut inter-champs

Un paramètre attribut d'un champs est lié dynamiquement à la valeur saisie dans un autre. L'exemple le plus courant est celui de deux champs qui décrivent un interval. On peut s'appuyer un "value" dynamique, ou un change qui met à jour le state du formulaire.

  // chiro > observations.json > count_max
  "count_max": {
    "min": "({value}) => value.count_min",
  }

  // efficacite_observateur/visit.json
  "change": [
    "({objForm, meta}) => {",
    "const journee_date_fin = objForm.value.visit_date_min;",
    "if (objForm.controls.visit_date_min.valid) {",
      "objForm.patchValue({'visit_date_max':journee_date_fin})",
      "}",
    "}",
    ""
  ]

interval --> validation
remplir le max en fonction du min --> comfort de saisie

Valeurs possible d'une liste

Les valeurs proposées par un menu déroulant peuvent dépendre directement de la valeur saisie dans un autre.

  // sterf/site.json > habitat_2
  "values": [
        "({value}) => {",
        "  if (value.habitat_1 == 'A. Forêt (arbres > 5m de hauteur)') { return [ 'a. Feuillus exclusifs','b. Mixte dom. Feuillus (< 10% conifères)','c. Mixte dom. conifères (< 10% feuillus)','d. Conifères exclusifs','e. Mixte' ] }",
        "  if (value.habitat_1 == 'B. Buissons ou jeune forêt (<5m de hauteur)') { return [ 'a. Feuillus exclusifs','b. Mixte dom. feuillus (< 10% conifères)','c. Mixte dom. conifères (< 10% feuillus)','d. Conifères exclusifs','e. Mixte' ] }",
        "  if (value.habitat_1 == 'C. Pelouses, marais et landes') { return [ 'a. Pelouse calcaire sèche','b. Lande herbacée','c. Lande à bruyères','d. Autres pelouses sèches','e. Pelouse d altitude', 'f. Pelouse humide naturelle', 'g. Pelouse inondée/marais pâturé', 'h. Tourbière', 'i. Roselière', 'j. Marais salant (halophile)', 'k. Autres zones humides ouvertes' ] }",
        "  if (value.habitat_1 == 'D. Milieux agricoles') { return [ 'a. Prairie cultivée','b. Prairie non cultivée','c. Prairie / cultures mixtes','d. Grandes cultures','e. Vergers / vignes / cultures maraîchères','f. Autres types de cultures' ] }",
        "  if (value.habitat_1 == 'E. Milieux bâtis ou urbanisés') { return [ 'a Zone urbaine résidentielle','b Zone urbaine industrielle','c Zone suburbaine résidentielle','d Zone suburbaine industrelle','e Zone rurale' ] }",
        "  else { return [ 'a. Falaise','b. Eboulis, pente rocheuse','c. Carrière','d. Autres sols rocheux' ]} ",
        "}"
      ]

valeurs possibles --> validation

Modification du state lors de modification dans le formulaire

Des modifications complexes du state.

  // petite_chouette_montagne/observation.json
  // mise à jour du state lors de modification dans le formulaire. Ca c'est
  "change": [
    "({objForm, meta}) => {",
      "const nb_passereau = null;",
      "const chev_chant = null;",
      "const sexe = null;",
      "const nb_total = (objForm.value.nb_before_rep + objForm.value.nb_repasse);",
      "const nb_hulotte = 0;",
      "objForm.patchValue({nb_total});",
      "(objForm.value.cd_nom != (null || undefined) && objForm.value.cd_nom != 3507 ? objForm.patchValue({nb_passereau}) : '');",
      "(objForm.value.cd_nom != (null || undefined) && objForm.value.cd_nom != 3507 ? objForm.patchValue({chev_chant}) : '');",
      "(objForm.value.cd_nom != (null || undefined) && objForm.value.cd_nom != 3507 ? objForm.patchValue({sexe}) : '');",
      "(objForm.value.hulotte != 'Oui' ? objForm.patchValue({nb_hulotte}) : '');",
  "}",
  ""
  ]

modification du state --> description. ne devrait pas être de la validation

List - valeur en bdd

"id_nomenclature_statut_obs": {
  "type_widget": "nomenclature",
  "attribut_label": "Contact",
  "code_nomenclature_type": "STATUT_OBS",
  "type_util": "nomenclature",
  "required": true
},

List - contrôle de nomenclatures (habitats, users, etc.)

"id_nomenclature_statut_obs": {
  "type_widget": "nomenclature",
  "attribut_label": "Contact",
  "code_nomenclature_type": "STATUT_OBS",
  "type_util": "nomenclature",
  "required": true
},

Evolution de syntaxe - JSON Schema

On souhaite ici faire évoluer la syntaxe des protocoles, pour intégrer la description de la validation.

Un premier échange avec Amandine et Camille a conduit à la décision d'intégrer jsonschema. D'une part parcequ'il est largement utilisé dans GN, et d'autres part parcequ'il n'y a pas réellement d'alternative.

Stack jsonschema

On utilise le formalisme jsonschema pour décrire les données issues du formulaire à des fins de validation.

JSON Schema est un formalisme utilisé pour décrire et valider automatiquement la structure et le contenu des documents JSON. Il permet de définir clairement les règles qu’un fichier JSON doit respecter (types de données, champs obligatoires, formats, etc.), ce qui facilite la détection d’erreurs dès le développement. Il est particulièrement utile pour la documentation, l’échange de données entre services, et la génération automatique de formulaires ou d’API, assurant ainsi cohérence, robustesse et interopérabilité.

Voir: https://json-schema.org/

La validation côté front est confiée à AJV

AJV (pour Another JSON Schema Validator) est une bibliothèque JavaScript / TypeScript très populaire pour valider efficacement des données via des schémas JSON Schema
https://ajv.js.org/

L'utilisation d'outil gérant automatiquement ce type de schéma en front, comme jsonforms ou formly, n'est pas compatible avec l'approche de monitoring dynamic-form-generator.

La validation côté back est confiée au paquet jsonschema.

Le paquet jsonschema pour Python est une implémentation de la spécification JSON Schema, qui permet notamment la validation.
https://pypi.org/project/jsonschema/

Compatibilité des exigences de et jsonschema

1. required suivant présence d'un champs

jsonschema prévoit exactement ce cas avec le mot clef "dependentRequired".

https://json-schema.org/understanding-json-schema/reference/conditionals#dependentRequired

{
  "type": "object",

  "properties": {
    "hulotte": { "type": "string" },
    "nb_hulotte": { "type": "number" },
  },

  "dependentRequired": {
    "hulotte": ["nb_hulotte"]
  }
}

2. required suivant la valeur d'un autre champs

jsonschema permet de déclarer un if else then pour déterminer la propriété required, qui couvre le cas en question.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "hulotte": { "type": "string" },
    "nb_hulotte": { "type": "number" },
  },
  "required": ["hulotte"],
  "allOf": [
    {
      "if": {
        "properties": { "hulotte": { "const": "Oui" } }
      },
      "then": { "required": ["nb_hulotte"] }
    }
  ]
}

3. list values

On peut également utiliser le if else pour déterminer le contenu de la liste.

A noter que ceci ne peut pas être utilisé pour faire varier les valeurs dans le formulaire dynamiquement

{
  "type": "object",
  "properties": {
    "list_parent": {
      "type": "string",
      "enum": ["p1", "p2"]
      // ou sans "enum si inconnu"
    },
    "list_child": {
      "type": "array",
      "items": { "type": "string" }
    }
  },
  "required": ["list_parent", "list_child"],
  "allOf": [
    {
      "if": {
        "properties": { "list_parent": { "const": "p1" } }
      },
      "then": {
        "properties": {
          "list_child": {
            "items": { "type": "string", "enum": ["p1__c1", "p1__c2"] }
          }
        }
      }
    },
    {
      "if": {
        "properties": { "list_parent": { "const": "p2" } }
      },
      "then": {
        "properties": {
          "list_child": {
            "items": { "type": "string", "enum": ["p2__c1", "p2__c2"] }
          }
        }
      }
    }
  ]
}

4. interval

Par défault, JSON Schema ne propose pas de vision interchamps. Plusieurs solutions existent pour contourner ce problème.

On peut:

• la création d'une validation custom

Les librairies de validation permettent d'ajouter un mot clef auquel on peut associer une validation personnalisée.
Cela permet notamment de définir un mot clef fonctionnel, facilement compréhensible par l'utilisateur.

schema = {
    "type": "object",
    "properties": {
        "start": {"type": "number"},
        "end": {"type": "number"},
        "low": {"type": "number"},
        "high": {"type": "number"}
    },
    "required": ["start", "end", "low", "high"],
    "x-minLessThanMax": [
        {"minField": "start", "maxField": "end"},
        {"minField": "low", "maxField": "high"}
    ]
}

ajv.addKeyword({
  keyword: "x-minLessThanMax",
  type: "object",
  compile(sch, parentSchema) {
    return (data) => {
      for (const {minField, maxField} of sch) {
        if (data[minField] >= data[maxField]) return false;
      }
      return true;
    };
  },
  errors: false
});

from jsonschema import Draft7Validator, validators

def validate_minless(validator, rules, instance, schema):
    if not isinstance(instance, dict):
        return
    for rule in rules:
        a, b = rule["minField"], rule["maxField"]
        if a in instance and b in instance and instance[a] >= instance[b]:
          yield ValidationError(f"'{a}' doit être < '{b}'")

CustomValidator = validators.extend(Draft7Validator, {"x-minLessThanMax": validate_minless})

L'implémentation python de JSONSchema prévoit de pouvoir ajouter un validateur custom CustomValidator(schema), qui serait appliqué sur le champs x-minLessThanMax.

L'inconvénient et qu'il faudrait également développer la validation client, et reproduire ces étapes à chaque besoin de validation multichamps.

• l'utilisation de $data

AJV permet l'utilisation de l'élément $data, qui contient une vision de l'objet du formulaire.

schema = {
    "type": "object",
    "properties": {
        "min": {"type": "number"},
        "max": {
            "type": "number",
            "minimum": {"$data": "1/min"}
        }
    },
    "required": ["min", "max"]
}

Ici, on indique que le minimum du champs max est la valeur "1/min" dans $data en partant de "max".

Afin de gérer ce comportement en backend, on peut réaliser un resolver, qui crée dynamiquement un schéma avec les valeurs adaptées.
Comme il sagit d'une modification du schéma de validation spécifique à une ligne, on déconseille l'utilisation de cette solution, sauf si c'est incontournable.
En effet, dans le cas de l'import par exemple, on va vouloir optimiser le traitement en calculant le validateur une fois pour tout l'import, et pas à chaque ligne (dynamique).

A vérifier avec les cas d'usages de monitoring.

"minimum": {"$data": "1/min"}
// deviendrait
"minimum": 12 // (par exemple)

def resolve_data_references(schema, instance, base_path=""):
    """
    Recursively replace {"$data": "<json-pointer>"} with actual value
    from the instance.
    """
    if isinstance(schema, dict):
        if "$data" in schema:
            pointer = schema["$data"]
            # The pointer in AJV $data is relative to the data level,
            # here let's assume it's a JSON pointer without the initial "/"
            # or with a number of "../" encoded as a prefix "1/", etc.
            # For simplicity, assume absolute pointer starting with '/'
            # Adjust this part if needed.

            # Simple JSON pointer implementation:
            parts = pointer.lstrip("1/").split("/")  # naive remove '1/' prefix
            value = instance
            try:
                for part in parts:
                    if part == "":
                        continue
                    value = value[part]
                return value
            except (KeyError, TypeError):
                raise ValueError(f"Cannot resolve $data pointer '{pointer}' in instance")

        # Recurse for all keys
        return {k: resolve_data_references(v, instance, base_path + "/" + k) for k, v in schema.items()}

    elif isinstance(schema, list):
        return [resolve_data_references(item, instance, base_path) for item in schema]

    else:
        return schema

5. Listes avec valeurs en bdd (nomenclatures, etc.)

Côté frontend, on modifie actuellement protocole dynamiquement, au sein de la méthode resolveDependency.
On peut décider d'adapter ce traitement dans la section jsonschema, déléguée à la validation.

from jsonschema import validate, ValidationError

def validate_input(data, valid_nomenclatures):
    schema = {
        "type": "object",
        "properties": {
            "mon_champ_nomenclature": {
                "type": "string",
                "enum": valid_nomenclatures
            }
        },
        "required": ["category"]
    }
    validate(instance=data, schema=schema)

Côté backend, on peut reproduire la mécanique, et injecter des valeurs dynamiquement dans le schéma de validation.

A noter que cela ne devait pas entrainer de surcoût dans l'import monitoring.
Un validateur peut-être pré-calculé et ensuite appliqué à plusieurs entrées.

6. Listes avec valeurs en bdd (très grande liste)

Dans le cas d'une très grande liste, la solution de rappatriement n'est pas adaptée. On pense par exemple au cas des habitats

  // chronoventaire > site.json
  "CodeHabitatStation1":{
    "type_widget": "datalist",
    "attribut_label": "Type d’habitat principale autour de la station",
    "api": "habref/habitats/autocomplete",
    "application": "GeoNature",
    "keyValue": "cd_hab",
    "keyLabel": "search_name",
    "type_util": "habitat",
    "params": {
        "cd_typo": 7,
        "search_name": "",
        "limit": "999999"
    }
  }

Dans ce cas, on peut mettre en place un validateur personnalisé, associé à ce champs. On peut, à l'interieur de ce validateur, atteindre les valeurs d'autres attributs du même champs, ou transmettre des paramètres. Il y a un choix à effectuer entre les deux approches, qui dépendra certainement du niveau de généricité que l'on veut donner à cette méthode.
On peut avoir une approche spécifique aux usage (utilisateurs, habitats, etc.). Ou une approche qui interprète le contenu d'un datalist, en parsant api, type_util, etc.\

Il est possible d'avoir un validateur qui se comporte de la même manière que le front de monitoring, en interprétant le valeurs params et api.
La manière la plus directe est l'approche par paramètre de même niveau. Ceci dit, l'approche par paramètre enfant reflète mieux la réalité de la relation entre les attributs. A choisir.

En prenant l'exemple ci dessus, et en simplifiant nettement à des fin illustratives, en considérant le validateur habitat, et le paramètre cd_typo, on obtiendrait:

cd_typo en paramètre enfant

schema = {
    "type": "object",
    "properties": {
        "CodeHabitatStation1": {
            "type": "array",
            "items": {"type": "string"},
            "x-habitat": {
                "cd_typo": 7,
            }
        }
    },
}

# Validateur avec paramètres multiples
def habitat_validator(validator, params, instance, schema):
    # On récupère la valeur de cd_typo
    cd_typo = params.get("cd_typo")

CustomValidator = extend(Draft7Validator, {
    "x-habitat": habitat_validator
})

cd_typo en paramètre du même niveau

{
    "type": "object",
    "properties": {
        "CodeHabitatStation1": {
            "type": "array",
            "items": {"type": "string"},
            "x-habitat": true,
            "cd_typo": 7,
        }
    },
}

# Validateur avec paramètres multiples
def habitat_validator(validator, params, instance, schema):
    # On récupère la valeur de cd_typo depuis la racine json
    cd_typo = instance.get("CodeHabitatStation1").get("cd_typo")

CustomValidator = extend(Draft7Validator, {
    "x-habitat": habitat_validator
})

Intégration de jsonschema aux protocoles monitoring

On souhaite intégrer ces nouveaux éléments de syntaxes aux protocoles monitoring.
On souhaite également conserver la description des protocols actuelle, et la définition du formulaire.
On souhaite ici enrichir l'existant, en explicitant la validation avec la syntaxe décrite précédemment.

Changer l'existant n'a pas été envisagé. Cela poserait des problèmes évidents de compatibilité, de temps de développements, etc.
Monitoring repose aujourd'hui beaucoup sur la structure actuelle.

Pour illustration, on va prendre le cas du visit.json d'un protocole imaginaire. Dans ce fichier .json, on se concentrera seulement sur la section "specific".

On a fait l'hypothèse que la section "generic" ne peut être surchargée que pour des raisons de description du formulaire 'ex: changer label du champs', et que cela n'intervient pas dans la validation
EDIT: Cette hypothèse est en réalité fausse. generic peut-être utilisé pour durcir les valeurs prédéfinis (restreindre une liste, rendre obligatoire un champs optionnel)

{
  // ...
  "specific": {
    "truc": {
      "type_widget": "select",
      "attribut_label": "Sélection d'un truc",
      "values": ["truc", "bidule ", "machin"]
    },
    "comment": {
      "type_widget": "text",
      "attribut_label": "Commentaire du bidule",
      "hidden": "({value}) => value.truc == null",
      "required": "({value}) => value.truc != null"
    }
  }
}

Dans cete implémentation, on sépare les informations de descriptions et de validations.
On ne touche pas à la "description". On enrichit le schéma d'une section "jsonschema", qui contient un jsonschema classique, avec les mêmes properties que les entrées de specific.

Aucun changement de l'existant

On peut mettre en place jsonschema, sans rien changer à l'existant. Ca entraine nécessairement quelque redites.

Dans cette version, on suppose qu'on ne change STRICTEMENT rien à l'éxistant.

{
  "jsonschema": {
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "type": "object",
    "properties": {
      "trucs": {
        "type": "string",
        "enum": ["truc", "bidule", "machin"]
      },
      "comment": {
        "type": "string"
      }
    },
    "allOf": [
      {
        "if": {
          "required": ["trucs"]
        },
        "then": {
          "required": ["comment"]
        },
        // le else sert à interdire
        "else": {
          "not": {
            "required": ["comment"]
          }
        }
      }
    ]
  },
  "specific": {
    "truc": {
      "type_widget": "select",
      "attribut_label": "Sélection d'un truc",
      "values": ["truc", "bidule ", "machin"]
    },
    "comment": {
      "type_widget": "text",
      "attribut_label": "Commentaire du bidule",
      "hidden": "({value}) => value.truc == null",
      "required": "({value}) => value.truc != null"
    }
  }
}

Changement de l'existant

On peut également mettre en place jsonschema, en déplacant les éléments de validations.

{
  "jsonschema": {
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "type": "object",
    "properties": {
      "trucs": {
        "type": "string",
        "enum": ["truc", "bidule", "machin"]
      },
      "comment": {
        "type": "string"
      }
    },
    "allOf": [
      {
        "if": {
          "required": ["trucs"]
        },
        "then": {
          "required": ["comment"]
        },
        // le else sert à interdire
        "else": {
          "not": {
            "required": ["comment"]
          }
        }
      }
    ]
  },
  "specific": {
    "truc": {
      "attribut_label": "Sélection d'un truc",
    },
    "comment": {
      "attribut_label": "Commentaire du bidule",
      "hidden": "({value}) => value.truc == null",
    }
  }
}

Cela supppose de:

• modifierla façon dont le protocole est parsé en front, pour fusionner les informations

On peut éditer gn_module_monitoring/frontend/app/services/config-json.service.ts > resolveProperty, pour que la méhode vienne également inférer l'information manquante telle qu'elle est attendue par le reste de monitoring.

Voir toForm

Il s'agit de pistes de réflection

• type: "string" + "values" ou "enum" --> type_widget: "select"
• type: "string" solo --> type_widget: "text"

De la même manière, on a la liste des valeurs d'un select, quand les valeurs sont figées, qui sera déplacée dans le jsonschema.

• confier ajv à la validation du formulaire, pour qu'il vienne modifier l'état de validité des FormControl du formulaire dynamique

Cela suppose que l'on arrive bien à s'intégrer au formulaire pnx-dynamic-form.
C'est à dire que l'on appelle "frontend/src/app/services/validators/validators.ts > addErrorToControl | removeErrorToControl". Ces méthodes s'appuient sur un enum qui contient les erreurs.

// Structure type d'une erreur AJV
{
  "instancePath": "/truc",
  "schemaPath": "#/properties/truc/type",
  "keyword": "format",
  "params": {
    "type": "email"
  },
  "message": "type must be \"truc_type\""
}

  // probablement FormService
  // Refact en cours: la solution n'est pas creusée.
  private ajv = new Ajv();
  private validateFn = this.ajv.compile(formSchema);

  ngOnInit(): void {
  this.form.valueChanges.subscribe((value) => {

    // on enlève les valeurs null de value
    const cleanedValue = this.cleanNullValue(value);

  // on fait tourner la validation
    const valid = this.validateFn(value);

    // Réinitialiser toutes les erreurs AJV prééxistantes dans le formulaire
    Object.keys(this.form.controls).forEach(key => {
      const control = this.form.get(key);
      if (control && control.errors) {
        const existingErrors = control.errors;
        for (const errorKey of Object.keys(existingErrors)) {
          if (errorKey.startsWith('ajv')){
            delete existingErrors[errorKey];
          }
        }
        control.setErrors(Object.keys(existingErrors).length ? existingErrors : null);
      }
    });

    // Normaliser les erreurs et les rajouter au composant
    if (!valid) {
      this.validateFn.errors?.map(err => {
        const field = (err.instancePath || '').replace(/^\//, '');
        const control = this.form.get(field);
        if (control) {
          const existingErrors = control.errors || {};
          existingErrors[`ajv_${err.keyword}`] = err.message;
          control.setErrors(existingErrors);
        }
        return `${field || err.schemaPath} ${err.message}`;
      });
    }
  });
}

specific, generic

En réalité, les protocoles sont constitutés de deux descriptions de formulaire: "specific" et "generic".

• Generic est décrit une seule fois.
• Specific est spécifié pour chaque protocole.

Il faut créer un schéma parent, qui combine les deux schémas.

// Schema specific
// Schema generic
export const combinedSchema = {
  type: "object",
  allOf: [schemaSpecific, schemaGeneric],
  // Important : limiter les propriétés autorisées
  properties: {
    ...schemaSpecific.properties,
    ...schemaGeneric.properties
  },
  additionalProperties: false
};

Si la fusion est trop complexe, ou problématique, on peut mettre additionalProperties: true Mais c'est plutot une moyenne/mauvaise pratique.

EDIT Restitution: une majeure partie de generic ne sera pas couverte par jsonschema.
additionalProperties: True est forcé

Gestion des cas particuliers / nouveaux

Pour gérer les cas particuliers, il est toujours possible de rajouter des validations personnalisées (cf range).

Validation backend

Dans la route

Une fois que l'information de validation est décrite dans une section jsonschema, le module monitoring est prêt à accueillir la validation côté backend.

Le plus judicieux parait être de rajouter une étape de validation dans le traitement des données associé la route qui permet de créer/modifier un objet monitoring

  # backend/gn_module_monitoring/routes/monitoring.py

  # recupération des données post
  **post_data** = dict(request.get_json())

Actuellement, les données sont traitées telles qu'elles.
Il faut rajouter un appel à la validation jsonschema, telles que traitées précédemment.
Les subtilités à mettre en oeuvre ont été traitées précédemment.

Cet ajout doit être délégué dans un object qui encapsule la gestion de la validation (ajout de custom validator, etc.).
On pourra alors réutiliser ce délégué sans problème lors de l'import monitoring/

Dans l'import

Lors de l'import, on peut compiler le validateur une fois, puis l'appliquer à chaque élément du dataframe avec une syntaxe type:

def valider_ligne_dataframe(donnees: dict):
    erreurs = [e.message for e in validator.iter_errors(donnees)]
    return erreurs if erreurs else None

# Nouvelle colonne 'erreurs' contenant les messages d'erreur (ou None)
df["erreurs"] = df.apply(lambda row: valider_ligne(row.to_dict()), axis=1)

Une optimisation des contrôles sera a réaliser pour éviter que des checks soit réalisés par deuxfois lors de l'import.

Restitution 13 aout

Generic EST modifiable

L'hypothèse d'un generic non modifié est en réalité fausse.
Generic peut-être modifié pour durcir les valeurs prédéfinis (restreindre une liste, rendre obligatoire un champs optionnel)

additionalProperties

Aujourd'hui, les checks réalisé par le backend sur generic sont satisfaisants, et ne seront pas intégrés à la validation réalisée ici.

additionalProperties devient nécessairement vrai, puisqu'on aura a minima tous les champs de generic non redéfinis. A savoir que la validation marshmallow permet déja de filtrer sur les champs non connus.

Cela permettra également de couvrir le cas des sites (données de site issues potentiellement d'un autre protocole).

Liste - données issues de bdd

Certaines valeurs possibles peuvnt être injectée, comme proposé dans le "5. Listes avec valeurs en bdd (nomenclatures, etc.)"
Un "6. Listes avec valeurs en bdd (très grande liste)" a été rajouté pour traiter les cas où les listes ne peuvent pas être injectée dynamiquement, par exemple dans le cas des habitats.

Mélange avec marshmallow

Les contrôles réalisés par marshmallow resteront réalisés avec marshmallow.
La validation jsonschema se concentre sur les champs additionnels.
Il n'y a pas de collision entre les deux.

[christophe-ramet]

Annnexe

Import V3 - Javscript dans les formulaires

Dissimuler le id_base_site

  // apollons > visit.json > id_base_site
  "params": [
    "({meta}) => ({",
    "id_module: __MODULE.ID_MODULE,",
    "id_sites_group: meta.parents.site && meta.parents.site.properties.id_sites_group,",
    "order_by: 'base_site_name*'",
    "})"
  ],
  "application": "GeoNature",
  "required": true,
  "hidden": "({meta, value}) => !meta.bChainInput && value.id_base_site"


  // cheveches > visit.json > id_base_site
  "params": [
    "({meta}) => ({",
    "id_module: __MODULE.ID_MODULE,",
    "id_sites_group: meta.parents.site && meta.parents.site.properties.id_sites_group,",
    "order_by: 'base_site_name*'",
    "})"
  ],
  "hidden": "({meta, value}) => !meta.bChainInput && value.id_base_site"

Eviter la saisie d'une ~constante

Quand on a qu'une seule valeur possible dans un champs.
On utilise le js sur hidden pour masquer le champs.

  // apollons > visit.json > id_dataset
  "hidden": "({meta}) => meta.dataset && Object.keys(meta.dataset).length == 1"

  // cheveches > visit.json > id_dataset
  "hidden": "({meta}) => meta.dataset && Object.keys(meta.dataset).length == 1"

  // chiro > visit.json > id_dataset
  "hidden": "({meta}) => meta.dataset && Object.keys(meta.dataset).length == 1"

  // ecrevisses_pattes_blanches > visit.json > id_dataset
  "hidden": "({meta}) => meta.dataset && Object.keys(meta.dataset).length == 1"

  // flore_biotope > visit.json > id_dataset
  "hidden": "({meta}) => meta.dataset && Object.keys(meta.dataset).length == 1"

  // ligne_lecture > visit.json > id_dataset
  "hidden": "({meta}) => meta.dataset && Object.keys(meta.dataset).length == 1"

  // nidif_gypa > visit.json > id_dataset
  "hidden": "({meta}) => meta.dataset && Object.keys(meta.dataset).length == 1"

  // prairies_fleuries
  // pt_ecoute_avifaune

  // efficacite_observateur.visit > id_dataset
  // prospection_gite/visit.json

Champs conditionnel

La pertinence de l'existence d'un champs peut dépendre du statut d'un autre.
Le js peut être utilisé pour mettre en place cette relation.

  // guano > visit.json > guano_comment
  "hidden": "({value}) => !value.guano_presency"

  // flore_biotope > visit.json > plein plein
  "hidden": "({value}) => value.test_detectabilite"

  // flore_biotope > visit.json > plein plein
  "hidden": "({value}) => !value.presence_tgb_hors_placette && value.test_detectabilite"

  // suivi_Camphi_gmb/visit.json
  // suivi_colo_chiro_gmb/sites_group.json
  // suivi_colo_chiro_gmb/visit.json
  // suivi_loutre_UICN_gmb/visit.json

Voir couplé au required

  // petite_chouette_montagne > observation.json > nb_hulotte
  "hidden": "({value}) => value.hulotte != 'Oui'",
  "required": "({value}) => value.hulotte == 'Oui'",

  // petite_chouette_montagne > observation.json > chev_chant
  "hidden": "({value}) => (value.cd_nom != (null || undefined) ? value.cd_nom != 3507 : true)",
  "required": "({value}) => (value.cd_nom != (null || undefined) ? value.cd_nom == 3507 : false)"

  // petite_chouette_montagne > observation.json > plusieurs
  // POPAmphibien/observation.json
  // POPAmphibien/visit.json
  // POPReptile/observation.json
  // POPReptile/site.json
  // pt_ecoute_avifaune/visit.json
  // pyrales/visit.json
  // RHOMEOAmphibien/observation.json
  // RHOMEOOdonate/observation.json
  // RHOMEOOrthoptere/observation.json
  // stom/visit.json
  // suivi_Camphi_gmb/observation.json
  // suivi_Camphi_gmb/site.json
  // suivi_loutre_SACs_gmb/observation.json
  // suivi_loutre_UICN_gmb/observation.json
  // suivi_loutre_UICN_gmb/site.json
  // suivi_phytosocio/visit.json
  // suivi_terriers_blaireau_gmb/observation.json
  // prospection_gite/observation.json > heure_obs, count_min, count_max

Attribut inter-champs

Un paramètre attribut d'un champs est lié dynamiquement à la valeur saisie dans un autre
(exemple min max).
On utilise le js pour créer cette dépendance inter champs.

  // chiro > observations.json > count_max
  "count_max": {
    "min": "({value}) => value.count_min",
  }
  // micromam_analyse_pelotes_rejection_gmb > visit.json > visit_date_max
  "required": false,
  "required": "({value}) => value.pelotes == 'Oui'"

  // micromam_analyse_pelotes_rejection_gmb > visit.json > nombre
  "required": "({value}) => value.pelotes == 'Oui'",

  // sterf/observation.json
  "count_max": {
    "min": "({value}) => value.count_min "
  }

  // sterf/site.json > habitat_2
  "values": [
        "({value}) => {",
        "  if (value.habitat_1 == 'A. Forêt (arbres > 5m de hauteur)') { return [ 'a. Feuillus exclusifs','b. Mixte dom. Feuillus (< 10% conifères)','c. Mixte dom. conifères (< 10% feuillus)','d. Conifères exclusifs','e. Mixte' ] }",
        "  if (value.habitat_1 == 'B. Buissons ou jeune forêt (<5m de hauteur)') { return [ 'a. Feuillus exclusifs','b. Mixte dom. feuillus (< 10% conifères)','c. Mixte dom. conifères (< 10% feuillus)','d. Conifères exclusifs','e. Mixte' ] }",
        "  if (value.habitat_1 == 'C. Pelouses, marais et landes') { return [ 'a. Pelouse calcaire sèche','b. Lande herbacée','c. Lande à bruyères','d. Autres pelouses sèches','e. Pelouse d altitude', 'f. Pelouse humide naturelle', 'g. Pelouse inondée/marais pâturé', 'h. Tourbière', 'i. Roselière', 'j. Marais salant (halophile)', 'k. Autres zones humides ouvertes' ] }",
        "  if (value.habitat_1 == 'D. Milieux agricoles') { return [ 'a. Prairie cultivée','b. Prairie non cultivée','c. Prairie / cultures mixtes','d. Grandes cultures','e. Vergers / vignes / cultures maraîchères','f. Autres types de cultures' ] }",
        "  if (value.habitat_1 == 'E. Milieux bâtis ou urbanisés') { return [ 'a Zone urbaine résidentielle','b Zone urbaine industrielle','c Zone suburbaine résidentielle','d Zone suburbaine industrelle','e Zone rurale' ] }",
        "  else { return [ 'a. Falaise','b. Eboulis, pente rocheuse','c. Carrière','d. Autres sols rocheux' ]} ",
        "}"
      ]
  // sterf/site.json > habitat_3
  "values": [
        "({value}) => {",
        "  if (value.habitat_1 == 'A. Forêt (arbres > 5m de hauteur)') { return [ '1. Sous-bois dense','2. Sous-bois clair','3. Clairière et lisière','4. Parc (arbres épars et prairies)' ] }",
        "  if (value.habitat_1 == 'B. Buissons ou jeune forêt (<5m de hauteur)') { return [ '1. Forêt de régénération ou taillis','2. Buissons calcicoles','3. Lande arbustive non calcicole','4. Garrigue (calcaire) (Méditerr)','5. Maquis (non calcaire) (Méditerr)','6. Buissons de zones humides' ] }",
        "  if (value.habitat_1 == 'C. Pelouses, marais et landes') { return [ '1. Entouré de haies avec arbres','2. Entouré de haies de buissons','3. Entouré de ligne d arbres sans haie','4. Avec buissons épars','5. Sans buissons épars','6. Groupes isolés de 1-10 arbres','7. Autres limites de terrain (digue, fossé, mur, ...)' ] }",
        "  if (value.habitat_1 == 'D. Milieux agricoles') { return [ '1. Entouré de haies avec arbres','2. Entouré de haies de buissons','3. Entouré de ligne d arbres sans haie','4. Entouré de bandes herbeuses','5. Avec des groupes isolés de 1-10 arbres','6. Autre limite de terrain (digue, fossé, mur, ...)' ] }",
        "  if (value.habitat_1 == 'E. Milieux bâtis ou urbanisés') { return [ '1. Zones bâties prédominantes','2. Jardin','3. Parc public, zone de loisirs','4. Bord d une route (< 50 m)','5. Bord d un chemin de fer (< 50 m)','6. Décharge d’ordures' ] }",
        "  else { return [ '1. En montagne','2. En bord de mer','3. En bord de lac ou de rivière','4. Autre' ]} ",
        "}"
      ]
  // sterf/site.json > habitat_4
  "values": [
        "({value}) => {",
        "  if (value.habitat_1 == 'A. Forêt (arbres > 5m de hauteur)') { return [ 'a. Non perturbé','b. Peu exploité','c. Fortement exploité','d. Pâturé' ] }",
        "  if (value.habitat_1 == 'B. Buissons ou jeune forêt (<5m de hauteur)') { return [ 'a. Non perturbé','b. Peu exploité','c. Fortement exploité','d. Pâturé' ] }",
        "  if (value.habitat_1 == 'C. Pelouses, marais et landes') { return [ 'a. Non perturbé/non exploité','b. Fauché','c. Pâturé' ] }",
        "  if (value.habitat_1 == 'D. Milieux agricoles') { return [ 'a. Non exploité (jachère)','b. Fauché','c. Pâturé','d. Céréales','e. Arbres fruitiers','f. Autres cultures' ] }",
        "  if (value.habitat_1 == 'E. Milieux bâtis ou urbanisés') { return [ 'a. Avec peu d espaces verts (< 25 %)','b. Avec des espaces verts surtout composés de pelouses','c. Avec des espaces verts buissonants (parterres, friches)','d. Avec des espaces verts fortement arborés','e. Avec un (des) potager(s)' ] }",
        "  else { return [ 'a. A dominante calcaire avec végétation herbacée rase','b. A dominante calcaire avec végétation herbacée haute','c. A dominante calcaire avec végétation buissonnante','d. A dominante non calcaire avec végétation herbacée rase','e. A dominante non calcaire avec végétation herbacée haute','f. A dominante non calcaire avec végétation buissonnante' ]} ",
        "}"
      ]

Modification du state lors de modification dans le formulaire

Des modifications complexes du state.

  // petite_chouette_montagne/observation.json
  // mise à jour du state lors de modification dans le formulaire. Ca c'est
  "change": [
    "({objForm, meta}) => {",
      "const nb_passereau = null;",
      "const chev_chant = null;",
      "const sexe = null;",
      "const nb_total = (objForm.value.nb_before_rep + objForm.value.nb_repasse);",
      "const nb_hulotte = 0;",
      "objForm.patchValue({nb_total});",
      "(objForm.value.cd_nom != (null || undefined) && objForm.value.cd_nom != 3507 ? objForm.patchValue({nb_passereau}) : '');",
      "(objForm.value.cd_nom != (null || undefined) && objForm.value.cd_nom != 3507 ? objForm.patchValue({chev_chant}) : '');",
      "(objForm.value.cd_nom != (null || undefined) && objForm.value.cd_nom != 3507 ? objForm.patchValue({sexe}) : '');",
      "(objForm.value.hulotte != 'Oui' ? objForm.patchValue({nb_hulotte}) : '');",
  "}",
  ""
  ]

  // RHOMEOFlore/site.json
  "change": [
      "({objForm, meta}) => {",
          "const base_site_name = 'T' + (objForm.value.num_transect) + 'Q' + (objForm.value.num_placette);",
          "if (!objForm.controls.base_site_name.dirty) {",
              "objForm.patchValue({base_site_name})",
          "}",
      "}",
      ""
  ]

  // suivi_phytosocio/site.json
    "change": [
      "({objForm, meta}) => {",
          "const base_site_name = 'T' + (objForm.value.num_transect) + 'Q' + (objForm.value.num_placette);",
          "if (!objForm.controls.base_site_name.dirty) {",
              "objForm.patchValue({base_site_name})",
          "}",****
      "}",
      ""
  ]
  // efficacite_observateur/visit.json
  "change": [
    "({objForm, meta}) => {",
    "const journee_date_fin = objForm.value.visit_date_min;",
    "if (objForm.controls.visit_date_min.valid) {",
      "objForm.patchValue({'visit_date_max':journee_date_fin})",
      "}",
    "}",
    ""
  ]
  // prospection_gite/visit.json
  "change": [
    "({objForm, meta}) => {",
    "const journee_date_fin = objForm.value.visit_date_min;",
    "if (objForm.controls.visit_date_min.valid) {",
      "objForm.patchValue({'visit_date_max':journee_date_fin})",
    "}",
  "}",
  ""
  ]