Bonjour,
J’aimerais savoir si c’est possible de passer outre une contrainte en utilisant le code, car actuellement une contrainte force un élément front à être modifiable et j’essaye tant bien que mal à le mettre en lecture seul via la methode getField(“nom_logique”).setUpadatable(false) dans un initUpdateAll(). Mais cette façon ne fonctionne pas.
Bonjour
Désolé votre post est passé entre les mailles du filet…
Avez vous résolu votre problème ?
Si non pouvez nous nous fournir le paramétrage de votre contrainte et de votre code afin qu’on puisse mieux cerner le problème et voir comment le résoudre.
PS: Merci aussi de systématiquement indiquer le numéro de version complet (x.y.z) de votre instance.
Bonjour,
La solution qu’on a trouvé c’est d’ajouter un paramétrage pour désactiver les contraintes en fonction de notre profil pour éviter d’y toucher dans le code.
OK tant mieux si vous avez trouvé la solution (je comprends que vous avez habilité vos contraintes mais je me trompe peut être)
Nous voudrions quand même mieux comprendre ce qui vous a posé problème au cas où on nous repose la question : ce qu’on comprend de votre post initial c’est que vous avez une contrainte front (et donc pas (aussi) back ?) qui joue sur le caractère updatable d’un attribut. Cette contrainte fait ce qu’il faut dans le contexte d’un formulaire de saisie unitaire mais par contre cette contrainte pose problème dans le cas d’un formulaire de mise à jour en masse. C’est ça ?
Si oui il nous faudrait les informations demandées dans ma réponse précédente pour mieux cerner la cas précis dans lequel vous êtes et voir ce qui serait, de notre point de vue, la bonne approche.
On voulait rajouter un profil qui permettait d’update un seul champ via le code avec un if hasresponsability qui met a updatable false, sauf qu’il y avait déjà une contrainte front via simplicité qui empêchait de la modifier du coup c’était pour savoir si on pouvait bypass une contrainte front via le back. Et ce qu’on a fait du coup c’est de mettre notre if dans la contrainte en elle même.
Version 5.3.41 (ministère des armées)
C’est déjà ça que je voudrais expliciter: comment est configuré cette contrainte exactement ? Purement front ou front+back ? Car ça change beaucoup de choses
Ensuite, toute contrainte peut être habilitée, donc pour qu’une contrainte ne concerne pas le groupe X il suffit de ne l’habiliter qu’aux autres groupes (pour mémoire une contrainte non habilitée à un groupe s’applique à tous). Est-ce que c’est ce que vous avez fait ?
Autre stratégie possible mettre en dernier une contrainte habilitée à votre groupe X qui remet l’attribut modifiable ou non spécifiquement pour lui. Ainsi la contrainte applicable à tous pourra être “bypassée” pour ce groupe X.
Etc.
En outre je ne vois pas dans votre réponse mention de mise à jour en masse… Or le hook indiqué dans votre post initial initUpdateAll est uniquement dédié à ce mécanisme de mise à jour en masse. Pour le formulaire unitaire c’est initUpdate (ou initCreate/initCopy) qu’il faut utiliser
Pour mémoire, le code des hooks initXxxest toujours exécuté après les contraintes back (et, pour mémoire, à la validation du formulaire, les contraintes back se ré-executent avant le validate = avant le preValidate si vous l’avez implémenté)
En tout état de cause il est parfois compliqué d’analyser le comportement quand on mixe des contraintes back ou front+back et du code back dans les initXxx.