PréBarrages: les valeurs erronées ne sont pas conservées

changed milestone to %Version 4.15.0

added bug label

assigned to @gargani

By Dorchies David on 2021-12-14T13:05:14 (imported from GitLab)

changed milestone to %Version 4.15.1

unassigned @gargani

By Dorchies David on 2022-04-05T12:06:35 (imported from GitLab)

created merge request !141 (merged) to address this issue

By Grand Francois on 2022-05-12T16:06:46 (imported from GitLab)

mentioned in merge request !141 (merged)

By Grand Francois on 2022-05-12T16:06:47 (imported from GitLab)

En fait, il y a un exemple beaucoup plus simple qui provoque le même problème quelque soit le module de calcul utilisé.

Étapes pour reproduire:

charger l'exemple "Passe à bassins type"
aller sur le module "PAB: Nombre"
saisir une valeur négative sur le paramètre "Nombre de chutes"
se déplacer vers un autre module de calcul
revenir sur le module "PAB: nombre"

Résultat observé:

La valeur du paramètre est revenue à sa valeur initiale avant saisie.

Résultat attendu:

Qu'on retrouve la valeur saisie par l'utilisateur quand bien même elle n'est pas valide.

Écueil de l'expérience

On touche aux limites de l'exercice entre une interface qui est générée à la volée et un modèle de données qui ne peut enregistrer que des valeurs valides.

Le bon compromis faisable avec les fonctionnalités actuelles serait de vider le champs invalide dans le modèle afin que la valeur précédente ne réapparaissent pas par magie. Cela résoudrait aussi le bug décrit pour le pré-barrage.

Je suppose qu'il faut changer le titre de ce ticket pour élargir la question.

By Dorchies David on 2022-05-17T08:40:31 (imported from GitLab)

mentioned in issue jalhyd#309 (closed)

By Grand Francois on 2022-05-15T10:34:47 (imported from GitLab)

mentioned in issue #544 (closed)

By Dorchies David on 2022-05-17T09:12:20 (imported from GitLab)

added Doing label

assigned to @francois.grand

By Dorchies David on 2022-05-17T10:21:54 (imported from GitLab)

mentioned in commit 75156a23