Gestion des Actions de transition d'état dans isActionEnable

Bonjour,

je souhaite pour afficher ou pas une action d’une transition d’état en fonction de la valeur d’un attribut d’objet lié :

j’ai voulu le faire avec le hook isActionEnable or quand j’affiche les actions gérées par ce hook, mes actions de transition n’apparaissent pas.

je suis bloquée

j’ai du coup essayé d’utiliser une contrainte.

ça ne fonctionne pas car dans l’expression d’une contrainte, j’ai une erreur quand je référence un attribut d’un objet lié qui est pourtant bien créé comme attribut de mon objet : obj.getField(‘gdrResaRessource_fk.gdrRessourceTypeResa’).getValue()

Quelle erreur ? getField revoit null ?
Est ce une contrainte front ou back ?

Si on est sur le front, comme on est en javascript, le nom des champs est le nom complet avec des doubles underscore “__” à la place des points, le getField IHM fait le replace tout seul pour rendre compatible les 2 syntaxes. mais essayez avec un __ à la place du point.

Sinon est ce un champ à plusieurs niveaux de jointure ? auquel cas on faut mettre le chemin complet
fk1.fk2.fk3.field pour éviter les ambiguité d’unicité s’il existe plusieurs chemins pour mener à “field”.

Ou il y aune erreur de syntaxe ailleurs dans la contrainte.

Quel est le nom du champ sur l’IHM au debugger sur l’input ?

exemple d’un champ ramené sur le front :
<input class="form-control" value="Smartphone" id="field_demoOrdPrdId__demoPrdName" name="demoOrdPrdId__demoPrdName" data-type="3" maxlength="100">

l’erreur est : obj.getField(…) is undefined

l’expression de la contrainte :
obj.getField(“gdrResaRessource_fk__gdrRessourceTypeResa”).getValue().equals(“A_VALIDER”)

le champ sur le front :
select class=“form-control field-container” id=“field_gdrResaRessource_fk__gdrRessourceTypeResa” name=“gdrResaRessource_fk__gdrRessourceTypeResa” data-type=“7” disabled=""

En back le double __ ne marchera pas.
Il faut revenir à une syntaxe ‘.’ le front fait ce qu’il faut, c’était juste pour essayer.

De même le “equals” java est à éviter, il faut préférer “==” qui marche dans les 2 mondes (rhino en back et javascript font).

Et il faut préférer le getFieldValue()

Voici un exemple de différentes syntaxes qui marchent très bien :

  • la contrainte s’active si le nom est non vide
  • et l’action en impact s’affiche que si le nom en jointure est “SMITH”

c’est ce que je fais depuis le début et ça ne fonctionne pas :

Attributs déclarés dans mon objet CrbGdrResa :

contrainte déclarée dans l’objet CrbGdrResa :

le message d’erreur :

et c’est bien cette contrainte qui pose problème.

Le champ n’est pas présent dans l’objet au moment du test.

Pb de paramétrage sur la jointure ?
champ forbidden auquel cas il n’est pan envoyé sur l’IHM ?
autres hooks ?

Il me faut tout le paramétrage de l’objet et de la contrainte pour analyse, car je ne vois pas du tout ce qui ne fonctionne pas.

Pouvez vous m’envoyer par mail le module ou un accès à votre environnement ?

  1. De plus il faut utiliser obj.getFieldValue qui permet de ne pas planter en renvoyant null si le champ n’existe pas, il y a aura juste un warning dans les logs.

Ca ne corrigera pas forcement le test fonctionnel, mais ça évitera un popup javascript.

  1. Si le champ n’est pas forcement présent dans l’objet (en liste par exemple), il faut utiliser la contrainte que sur le contexte du formulaire : mettre par exemple [ISNEW] || [CONTEXT:UPDATE] dans la condition de déclenchement de la contrainte.

  2. vous pouvez enfin tester si le champ est présent dans l’expression :

obj.getField(“xxx”) ? obj.getFieldValue(“xxx”)==“XXX” : false

dans les hook de l’objet, je récupère sans pb le getField(“gdrResaRessource_fk.gdrRessourceTypeResa”).getValue() donc je ne vois pas ou il y aurait un pb de jointure

j’ai ajouté le [CONTEXT:UPDATE] et j’ai utilisé le obj.getFieldValue …

la contrainte n’est pas appliquée.

je t’envoie mon module pas mail. il est en dev, pas possible d’y accéder de l’extérieur

En back c’est normal car l’objet est complet.

En front en revanche, les metadata de l’objet ne sont pas forcement complètes (pour optimiser les listes par exemple / pas de champ forbidden…)

d’où la 3eme solution pour tester que le champ est présent quel que soit le contexte.

obj.getField("xxx") ? obj.getFieldValue("xxx")=="XXX" : false

Je vais regarder ton module.

dans ce cas, pourquoi ne peut-on pas scripter les actions de processus metier dans le isActionEnable ?

Il y a des contraintes front avec Tool.isEmpty, je doute que cela fonctionne car Tool est un objet static java.

obj.getFieldValue("gdrResaMvt") == ""

Le champ gdrResaRessource_fk.gdrRessourceTypeResa est bien visible qu’en formulaire, donc la contrainte lorsqu’elle est appelée sur la liste (il y a des actions de liste qui peuvent être contraintes) il est normal qu’un simple getField renvoit “null” sur l’IHM.

Sur le hook isActionEnable en back, tous les champs sont présents.
Il est appelé pour chaque action habilitée / donc on peut juste surcharger pour dire false, mais on ne peut pas ajouter un bouton non habilité. Je vais refaire des tests sur les transitions mais elles doivent normalement y passer aussi.

L’action en question pour l’aquelle je veux applique la contrainte n’est applicable qu’au formulaire. a devrait donc fonctionner.

et je te confirme que les actions de transitions ne passent pas dans le isActionEnable sinon, c’est ce que j’aurais utiliser.

Il y avait effectivement une différence de comportement avec l’ancienne IHM qui appelait isActonEnable sur une action de transition.

C’est corrigé pour que l’API JSON passe par le même hook si la transition est liée à une Action.
Cela va envoyer dans les metadata de la transition enabled = false à l’IHM qui va désactiver le bouton = il reste visible mais grisé.

S’il faut le masquer complètement, il faudra le faire par CSS / via une ressource STYLES sur l’objet ou la disposition :

.btn-transition.disabled { display: none; }

pour dire qu’une transition désactivée est masqué et pas simplement grisée.

Du coup la contrainte ne servira à rien, de mon côté elle marche très bien même si le champ n’est pas en liste (en testant bien l’existence du champ dans mon expression comme expliqué).

Il faut retenir qu’une contrainte “Front” ne peut pas faire tout ce que le back peut faire (accès réduit aux données ou aux APIs suivant le contexte d’affichage).

ok, dans le cas des actions, je vais utiliser le hook plutôt que les contraintes.
comme je le faisais en V3 d’ailleurs?

la correction sera dans la prochaine release ?

C’est normalement poussé depuis 5 minutes.

Le hook fonctionnera comme en V3 donc à l’affichage du formulaire.
Alors que la contriante “Front” permet de rendre dynamique à l’écran la règle de gestion si les champs en expression changent / le bouton s’active ou pas directement.

Donc si les champs contraints ne sont pas modifiables le hook est suffisant.
Sinon il faudra aussi paramétrer un contrainte Front pour que ce soit plus intuitif en terme d’UX pour l’utilisateur.