PréBarrages: les valeurs erronées ne sont pas conservées
- Charger l'exemple pré-barrage
- Sélectionner une cloison
- Mettre le coefficient de débit d'un ouvrage à 1000: le champ est alors en erreur et le bouton calculer est invalide
- Sélectionner un bassin ou une autre cloison
- Sélectionner un autre bassin ou une autre cloison: le bouton calculer redevient valide
- Retourner sur la cloison de départ: le coefficient de débit a été modifié à 10 (valeur max acceptée)
Comportement attendu: la valeur devrait être conservée ou effacée de façon à conserver l'information du champ mal saisi.
Activity
changed milestone to %Version 4.15.0
added bug label
changed milestone to %Version 4.15.1
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)
Edited by David Dorchiesmentioned 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
mentioned in commit 75156a23
By Grand Francois on 2022-05-17T14:58:29 (imported from GitLab)
mentioned in commit cf99e655
By Grand Francois on 2022-05-17T14:58:29 (imported from GitLab)
mentioned in commit 5ece8826
By Grand Francois on 2022-05-17T14:58:29 (imported from GitLab)
mentioned in commit affc3e2d
By Grand Francois on 2022-05-17T14:58:29 (imported from GitLab)
mentioned in commit 08c853c5
By Grand Francois on 2022-05-17T14:58:29 (imported from GitLab)
mentioned in commit df632167
By Grand Francois on 2022-05-17T14:58:29 (imported from GitLab)
François a écrit:
On ne souhaite conserver les valeurs erronées qu'en mode fixe.
En mode variable, les vérifications doivent obliger à annuler le dialogue en cas de valeurs invalides.
Comportement attendu:
Que ce soit en en mode fixe ou variable: les données erronées saisies sont supprimées (undefined)
Le ticket #545 (closed) sur le mode varié est lié à celui-ci.
By Dorchies David on 2022-05-18T11:57:28 (imported from GitLab)
marked this issue as related to #545 (closed)
By Dorchies David on 2022-05-18T11:57:39 (imported from GitLab)
mentioned in commit 425ae8fa
By Grand Francois on 2022-05-18T15:34:45 (imported from GitLab)
mentioned in commit b15a323f
By Grand Francois on 2022-05-18T15:34:45 (imported from GitLab)
marked this issue as related to jalhyd#309 (closed)
By Dorchies David on 2022-05-20T08:29:37 (imported from GitLab)
mentioned in commit 44eea74e
By Dorchies David on 2022-05-24T18:52:24 (imported from GitLab)
