Impact "valeur du champ" sur attribut de type entier ou décimal fait freeze le navigateur

FlorentGN · May 30, 2024, 3:30pm

Request description

Bonjour,

Afin de vider le contenu d’un attribut type entier si un autre champ de type booléen vaut “Non” j’ai créé une contrainte avec un impact permettant de changer la propriété de l’attribut “Valeur du champ”. La contrainte et son impact fonctionne bien quand l’attribut pour lequel je souhaite vider la valeur est de type texte court par exemple mais si le type de l’attribut est entier ou décimal la contrainte fait freeze le navigateur.

Steps to reproduce

A partir du module de démo :

J’ai ajouté un attribut de type booléen et un autre de type entier dans l’objet fournisseur :

J’ai ajouté la contrainte et les impacts suivant :

Après un clear cache, quand je teste la contrainte en modifiant la valeur du booléen l’application freeze.

Il semble également y avoir un problème avec les messages d’erreur “champ obligatoire” qui restent affichés après l’enregistrement alors que les champs sont bien non vides.

Technical information

Instance /health


[Platform]
Status=OK
Version=5.3.38
BuiltOn=2024-05-17 09:22
Git=5.3/cd9b92ec3c680f920be9b3109e12d35b9486fe29
Encoding=UTF-8
EndpointIP=
EndpointURL=
TimeZone=UTC
SystemDate=2024-05-30 15:30:29

[Application]
ApplicationVersion=1.0.0
ContextPath=
ContextURL=
ActiveSessions=1
TotalUsers=7
EnabledUsers=5
LastLoginDate=2024-05-30 15:11:55

[Server]
ServerInfo=Apache Tomcat/9.0.89
ServerType=WEB
ServerActiveSessions=1
ServerSessionTimeout=30
CronStarted=true

[OS]
Name=Linux
Architecture=amd64
Version=3.10.0-1160.114.2.el7.x86_64
DockerImageName=centos7
SystemEncoding=UTF-8

[JavaVM]
Version=17.0.11
Vendor=Eclipse Adoptium
VMName=OpenJDK 64-Bit Server VM
VMVersion=17.0.11+9
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.13 2020 09 02
HeapFree=203604
HeapSize=668672
HeapMaxSize=2007040
TotalFreeSize=1541972

[Cache]
ObjectCache=426
ObjectCacheMax=10000
ObjectCacheRatio=4
ProcessCache=426
ProcessCacheMax=10000
ProcessCacheRatio=4
APIGrantCache=0
APIGrantCacheMax=1000
APIGrantRatio=0

[Database]
Vendor=3
VendorName=postgresql
ProductName=PostgreSQL
ProductVersion=13.14 (Debian 13.14-1.pgdg120+2)
DriverName=PostgreSQL JDBC Driver
DriverVersion=42.7.3
DBDate=2024-05-30 15:30:29
DBDateOffset=0
DBPatchLevel=5;P03;29131276dea85455af3d320043396699;38
UsingBLOBs=true

[Healthcheck]
Date=2024-05-30 15:30:29
ElapsedTime=158

FlorentGN · May 31, 2024, 7:27am

Comme l’attribut est de type integer j’ai modifié mon impact pour mettre null au lieu de “” pour vider le contenu de celui-ci quand le booléen vaut non.

Je n’ai donc plus de freeze pour ce cas par contre quand je mets mon booléen à oui et que c’est [VALUE:demoSupInteger] qui s’applique j’ai toujours la page qui freeze. Est-ce qu’il existe une syntaxe pour faire en sorte que [VALUE:demoSupInteger] retourne un int et non un string et que cette solution soit compatible front et back ?

david · May 31, 2024, 7:45am

Y-a-t-il des messages dans la console du navigateur ?

Je pose la question pour comprendre la nature du problème ? Une simple erreur JS ou une boucle infinie qui part en vrille coté serveur ou coté client ? etc?

Il peut en effet y avoir des boucles infinies avec des contraintes qui effectuent des cycles : ex: C1 positionne A en fct de B, C2 positionne C en fct de B, C3 positionne A en fonction de C

Peut être qu’en fct des types des attributs le cycle s’arrete en rendant un test de contrainte faux ou dans le genre. En JS les tests sur les booléens sont toujours un peu confusants

Pour commencer ce serait intéressant de tester si le pb est front (JS) et/ou back (Rhino) en jouant sur le type de contrainte

Sinon [FIELD:monField].getInt(0) renverra un int depuis un attribut “entier” (et pas la chaine de caractères comme [VALUE:monField]). Ca marchera coté back en Rhino (car c’est une méthode Java de la classe ObjectField) mais je ne suis pas sûr que le getInt (et ses équivalents getBoolean, getFloat, …) existent coté JS front (je vais vérifier)

Par contre je ne comprends pas pourquoi une égalité simple poserait pb avec des chaines de caractères, en JS et en Rhino "3" == 3 est vrai ("3" === 3 est faux)