Contraintes et affichage dynamique dans un processus métier

Bonjour,

Nous souhaitons dans un use case, afficher une description associée à un attribut “produit” dans une étape d’un processus métier.

Actuellement, cela fonctionne correctement dans le formulaire de l’objet associé (les contraintes mettent bien à jour la description en fonction du produit sélectionné, affichage aussi si l’attribut à un produit ), nous avons 2 impact un de visibilité front-end et un autre de valeur de champ :

ezgif-2-f4558ba1c3

mais dans le contexte du processus métier, la description ne se met pas à jour dynamiquement au cours de l’activité.
Elle apparaît uniquement dans la synthèse, mais sans changer en fonction du produit choisi( dans le cas ou l’utilisateur change de produit).


Est-ce qu’il est prévu que les contraintes et impacts puissent s’appliquer nativement dans les processus métiers associé à un objet ? Ou bien devons-nous passer par un script JavaScript pour refaire cet affichage dynamique ? ( dans ce cas là passer par une ressource lié au processus métier ou la Responsive5 ? )

Je me posais aussi la question concernant les ressources lié à un processus métier :

Pour les ressources liées à un processus métier (JS et CSS), il n’est pas encore possible d’associer directement ces ressources à un processus spécifique. Nous les plaçons pour le moment dans Responsive5. Est-il prévu qu’à l’avenir, on puisse utiliser directement ces ressources dans le cadre d’un processus métier pour le personnalisé ? ( ou bien une mauvaise utilisation/compréhension de ma part).

Merci pour votre retour

Technical information

Instance /health
---Status=OK
Version=6.1.19
BuiltOn=2025-01-06 14:36
Git=6.1/793315cef5dfab9cb2ccefaaf0b870ed3a24e05d
Encoding=UTF-8
EndpointIP=100.88.206.228
EndpointURL=http://lbc-77449-app-5584889c69-bm52g:8080
TimeZone=Europe/Paris
SystemDate=2025-01-09 15:51:37---
Simplicité logs
---paste the content of the **relevant** server-side logs---
Browser logs
---paste content of the **relevant** browser-side logs---
Other relevant information

----E.g. type of deployment, browser vendor and version, etc.----

Bonjour,

L’encapsulation de l’objet dans une activité de processus surcharge effectivement certains comportements du formulaire “seul”, mais à priori les contraintes front s’appliquent.

Pour essayer de reproduire le comportement, pouvez vous nous donner la définition de la contrainte et des impacts ? vous dites qu’un seul s’exécute sur les 2 ?

Il se peut que le setValue sur le champ ne soit pas bien propagé dans le contexte de l’activité en mémoire (à faire en back au validate de l’activité par exemple).

Les contraintes si elles n’implémentent pas votre besoin peuvent être remplacées par du code front dans la classe hook de l’objet (legacy form.onload ou via la méthode de classe UI onLoadForm).

A noter : le front n’envoie pas de champ en read-only au back (ce qui semble être le cas de votre champ). Donc une règle front doit toujours être ré-implémentée en back (champ obligatoire, setValue…).

1 Like

Note:

Il vaut mieux utiliser la disposition default pour les ressources globales car c’est ce qui est pérenne => le 5 dans responsive5 c’est pour la version Bootstrap (actuellement en v5.x.y), lorsqu’un Bootstrap v6 sortira (ou si on passe sur un autre framework web low level) responsive5 sera deprecated et il y aura une nouvelle disposition responsive6 (ou un autre nom) qui deviendra la disposition standard de la UI

1 Like

Bonjour François, merci pour tes retours !

j’ai créé 2 contraintes avec un impact chacune, dans le formulaire de l’objet les 2 impacts marchent.

Cependant dans l’activité associé dans le processus métier,aucune des 2 ne se déclenchent à la sélection d’un produit,

cependant dans la dernière activités de synthèse qui remontre tous les Fields, le Field description et sa valeur du champs sont visible( donc entre-temps les 2 contraintes se sont activés mais pas de manière dynamique dans la 1er activités).
Cependant si je modifie le produit dans la dernière activité je ne le verrais que dans le formulaire…

Voici les informations des 2 contraintes :

ainsi que leur impacts,la 1ere pour la visibilité du field description en fonction du field product :

et le second pour set la valeur du champs ( pour le moment un test avec 2 valeur pour voir le comportement dynamique évolué ):

.

Ses contraintes implémentent très bien mon besoin c’est pour ca que je veux rester sur le standard en utilisant les impacts,en espérant juste voir ce comportement dans le processus :slight_smile: .

Bonjour,

Problème reproduit, en fait il manquait des évènements “change” sur les champs lié à des contraintes qui ne pouvaient donc pas être dynamiques.

De mémoire cela avait été initialement voulu pour pouvoir différencier les règles de gestion dans un formulaire seul ou dans un workflow, mais cela n’a jamais été implémenté.

Ce sera corrigé dans la prochaine livraison 6.1.20 pour appliquer les mêmes règles sous contraintes au sein du workflow.

2 Likes

This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.