J’ai une contrainte qui rend obligatoires certains champs. Cette contrainte fonctionne bien sous ma Vue principale, mais pas pour ma Vue qui utilise un Object Externe en tant que zone de vue.
Pourtant, les champs sont exactement les mêmes entre les 2 Vues (c’est le même formulaire). Voici ce que ma contrainte m’affiche dans ma Vue principal mais pas dans ma Vue avec un Objet Externe.
PS : Dès que je remplace la Vue avec Objet Externe par la Vue principale, les messages “Champs obligatoire” réapparaissent. Donc il ne s’agit pas d’un problème de droit.
Il y a peut être un pb lorsqu’on met un formulaire dans une zone de vue via un type de zone “objet externe”. Personnellement je ne ferais pas ce genre de chose… en tout cas pas comme ça.
Quel est le besoin qui vous a conduit à faire ça ?
Je pose la question car il y a peut être une meilleure approche.
L’objectif, c’était que quand une personne du groupe HR_APPLICANT se connecte, il tombe directement sur le formulaire sans avoir à naviguer sur l’application contrairement aux autres groupes.
C’est pour cette raison que nous avons une Vue pour le groupe HR_APPLICANT (celle avec l’Objet externe) et la Vue principal pour les autres groupes.
OK je vois le besoin. Je pense qu’utiliser un “objet externe” pour intégrer un formulaire d’objet métier standard dans la page d’accueil (qui plus est via une = pseudo URL legacy) n’est sans doute pas une bonne approche pour y répondre.
Dans la démo la page d’accueil du profil DEMO_ADMIN (DemoAdminHome) fait du JS pour ouvrir une page standard via l’API UI ad hoc, c’est plus comme ça que je le ferais:
En utilisant un $ui.displayForm(null, <object>,<row ID>, { nav:'add' }); avec <row ID> = '0' pour afficher le formulaire en création
Peut être qu’en intégrant un vrai objet externe à votre vue qui fait ce type de “redirect” JS (return javascript("$ui.displayForm(...)")) ça marche aussi (l’intérêt de l’objet externe étant ici de pouvoir calculer un row ID specifique coté serveur)
Si ça peut également aider à trouver l’origine du problème, même si les messages “Champs obligatoire” ne s’affichent pas dans ma vue, la contrainte semble bien être pris en compte car je ne peux pas envoyer le formulaire sans avoir rempli tous les champs obligatoires. Si je le fais pas, il n’y a pas de message, mais rien ne se passe.
Du coup, le problème ne vient pas de la contrainte en elle-même, mais des messages d’erreur “Champs obligatoire” qui ne sont pas renvoyés par cette dernière.
Sachant, j’ai d’autre messages du même type qui doivent remonté si la condition n’est pas rempli (bon format de fichier), et ces messages ne remonte pas aussi (appelé dans la méthode preValidate()).
Comme dit plus haut, il y a sans doute un effet de bord lié à la manière “atypique” dont vous intégrez un formulaire standard dans une vue au travers d’un mécanisme qui n’est clairement pas conçu pour ça.
Du coup ça marche à moitié et ça ne m’étonne pas vraiment. Nous n’investiguerons pas ça, ou alors plus tard et en priorité basse.
Suivez plutôt les patterns que je vous ai indiqués qui sont plus nominaux.
Par contre je mettrais null à la place de votre '#work' (null voulant dire ici “dans le container par défaut”). A voir si ça change quelque chose.
Sinon il faudra qu’on creuse ce cas, pour cela il faudra décrire précisément vos contraintes pour qu’on essaie de reproduire (au passage avez vous checké les logs serveur et navigateur pour voir s’il n’y a pas d’éventuels messages ?)
J’ai remplacé par null, mais rien ne change, les message “Champs obligatoire” n’apparaissent pas. return javascript("$ui.displayForm(null, 'HrNewEmployee', " + rw_id + ", null);");
J’ai vérifié les logs, quand je clique sur la transition d’état (c’est le moment ou la contrainte est appelée), il n’y a pas d’erreur, mais les messages “Champs obligatoire” n’apparaissent pas.
Surtout vos conditions d’impact ne sont, je pense, pas uniquement liée à une transition d’état mais à un état => Dans l’état X les attributs x sont obligatoires cela inclus le cas de la transition vers l’état X et aussi que la règle reste appliquée pour les éventuelles mises à jour des records qui sont déjà dans l’état X.
Pour vérifier si vos expressions contraintes s’appliquent vous pouvez écrire des fonctions auto appelantes du genre:
Normalement vous verrez alors (ou pas) passer les messages dans les logs serveur (car il s’agit d’une contrainte “back”) et remontées via websocket dans la console du navigateur. Ca permettra de savoir si c’est un pb d’exécution des contraintes dans ce contexte particulier (auquel cas le pb est chez nous) ou si ce sont les contraintes elles même qui ne font pas ce que vous voulez (auquel cas le pb est chez vous).
Lorsque je passe sur mon utilisateur qui possède la Vue avec l’objet externe, dans les logs, j’ai bien le message qui apparait quand je réalise la transition d’état.
Cependant les messages “champs obligatoire” n’apparaissent toujours pas. Du coup, on peut voir que la contrainte est bien exécutée, mais les messages, ne sont pas remontés.
Comme dit plus haut, si les contraintes s’exécutent c’est que le pb n’est pas dans la “mécanique” du socle Simplicité.
Je vous laisse relire ma réponse précédente sur la fait que je trouve fonctionnellement “douteux” que vous n’y gériez que le cas de la transition d’état.
Dans votre fonction auto appelante essayez de tracer plus de choses pour comprendre pourquoi la condition de votre expression n’est pas remplie dans ce cas.
La condition de mon expression dans ma contrainte est remplie, puisque si je ne remplis pas tous les champs obligatoires, ma transition d’état ne me fait pas passer à l’état suivant quand je clique dessus. C’est juste les messages “Votre champ est obligatoire” qui ne sont pas remonté. Du coup, ça donne l’impression que rien ne se passe.
Mais si je remplis tous les champs, ma transition d’état fonctionne.
Voici les messages qui devraient être remontés mais qui ne le sont pas :
De plus, il ne faut pas oublier que tout fonctionne lorsque je suis sur ma Vue principal et pas sur la Vue spécial avec l’objet externe.
Je le redis, une contrainte qui ne gère qu’une transition d’état est sans doute pas la bonne à chose à faire.
Fondamentalement votre règle c’est de dire que l’attribut X est obligatoire dans l’état Y, pas que l’attribut X est obligatoire uniquement au moment où on passe de l’état Z à Y.
Sinon la différence entre le cas du formulaire principal et ce formulaire obtenu par un autre chemin doit être la présence ou pas des old values. @Francois tu as un avis/conseil sur ce point ?
Et puis si c’était un problème de old_value, quand je clique sur ma transition d’état, ma condition dans l’expression ne serait pas VRAI et je pourrais passé à l’état suivant sans avoir rempli tous les champs obligatoire, ce qui n’est pas le cas ici.
Je suis 100% sûr que quand je clique sur ma transition d’état, mon expression dans ma contrainte fonctionne parfaitement et vérifie si tous les champs obligatoires sont remplis. Si tous les champs obligatoires sont remplis, je passe à l’état suivant (C’est le cas), si tous les champs ne sont pas rempli, je ne passe pas à l’état suivant (C’est le cas) et je remonte les messages indiquant que les champs sont obligatoires et que l’utilisateur doit les remplir (C’est pas le cas uniquement dans la Vue spéciale).
Comme dit plus haut tracez plus de choses (values et old values) dans vos contraintes pour mieux cerner ce qu’il se passe exactement dans les deux cas et où se situe la différence.
Reste que je persiste à considérer qu’une contrainte ne portant que sur une transition d’état n’est sans doute pas une bonne chose.
Ex: l’attribut A est non obligatoire dans l’état X, une contrainte le rend obligatoire dans le cas où on passe de X à Y. Pour passer à Y je renseigne donc l’attribut A, mon record se trouve alors dans l’état Y. Je ferme et je réouvre le formulaire, je vide l’attribut A et j’enregistre (ici la contrainte ne s’applique pas car on est plus dans une transition d’état). Je me retrouve alors avec un record dans l’état Y avec l’attribut A vide ce qui n’est sans doute pas ce que je voulais.
Le seul cas où ça peut être suffisant de gérer uniquement le cas de la transition c’est si Y est un état final ou lecture seule, mais dans tous les cas il vaut mieux contraindre sur l’état Y car ça marchera aussi pour la transition de X vers Y, la réciproque est fausse.
OK mais si vous testiez uniquement l’état ça marcherait pareil et ça serait plus évolutif pour d’éventuels cas futurs où un attribut devient obligatoire dans un état donné mais peut malgré tout rester modifiable. Tester la transition n’a aucune plus value vs tester l’état cible.
