Contraintes front des zones d'attributs incorporés ne s'appliquent pas dynamiquement

Problem description

Les contraintes front de visibilité de champs définies sur un objet qui fonctionnent bien en ‘standalone’ ne fonctionnent pas lorsque le formulaire est incorporé dans un autre objet (relation 1-1). Il faut sauvegarder/recharger le formulaire incorporant pour que la contrainte s’applique sur les champs incorporés.

Steps to reproduce

En mode incorporé :
Sélection d’une option dont la valeur est contrôlée dans une contrainte / impact de visibilité sur le champ situé en dessous
→ le champ masqué ne s’affiche pas

Enregistrement intermédiaire
→ le champ masqué s’affiche

En mode ‘standalone’ :
Situation initiale avec la valeur vide du champ pilotant la contrainte
→ le champ ciblé par la contrainte est masqué

Sélection d’une option dont la valeur est contrôlée dans une contrainte / impact de visibilité sur le champ situé en dessous
→ le champ masqué s’affiche instantanément

Technical information

Instance /health
---[Platform]
Status=OK
Version=5.1.33
BuiltOn=2022-03-04 00:03
Git=release/978e61bd62362c6d2d4dcd5146d232263107e1c8
Encoding=UTF-8
EndpointIP=21.0.9.5
EndpointURL=http://b65be8246dd9:8080
TimeZone=Europe/Paris
SystemDate=2022-03-16 14:27:18
---
Simplicité logs
---NA---
Browser logs
---NA---
Other relevant information

----NA----

Les champs de lien 0,1 ou 1,1 incorporés/inlinés sont conçus pour des usages assez simples comme intégrer un rib, une adresse… ce cas de contraintes “filles” n’a jamais été vraiment testé.

La cas reste étrange car c’est bien un displayForm qui est fait pour afficher le formulaire fils au lieu d’une liste. Celui-ci est donc sensé charger les contraintes = ici attacher les events “change” sur le champ. Il doit y avoir un pb de localisation ou de chargement des contraintes au niveau de fils. On va corriger.

Par contre, j’ai un doute pour faire fonctionner une contrainte entre un champ de l’objet père avec un impact sur la ligne fille incorporée en formulaire, qui serait plus une feature request car ce n’est clairement pas implémenté, mais restera surement faisable si les attributs sont bien identifiables une fois chargés. Je vais tester ce cas au passage.

Dans mon cas d’usage, la contrainte et les impacts n’impliquent que des champs propres à l’objet incorporé (i.e. pas de valeur issue de l’objet incorporant, fusse via une fk dans l’incorporé). Mais c’est un cas particulier/simple.

C’est corrigé. Il manquait bien les binding des “change” sur les champs pour exécuter les contraintes.

Testé sur un cas simple de contrainte Front de visibilité en cascade “type / sous-type” en changeant sur la Demo le lien Contact => Commande en cardinalité 1,1 avec Champs incorporés.

Ce sera livré en 5.1.35.
@bmo

1 Like