Mince je pense que j’ai compris de travers :-/
J’ai besoin que ma contrainte s’applique en back car j’ai un calcul qui dépend de la visibilité / updatabilité des champs. Ne peut-on pas afficher la colonne dans tous les cas si c’est le paramétrage du champ à la base, et n’appliquer la contrainte que sur la valeur de la ligne ?
Sinon comment faire ? J’ai beaucoup de contraintes de ce type donc c’est un peu lourd de dupliquer le fonctionnement des contraintes dans le code back.
C’est ce que ça fait.
En back, il n’existe pas de notion visibilité en cellule de liste.
Le champ doit être visible en liste
Et la contrainte doit s’appliquer uniquement en front pour que le cellule soit masquée en fonction de la règle par ligne.
Sur l’implémentation, pourquoi un calcul dépend de la visibilité qui reste une notion purement UI.
La règle de calcul doit dépendre de la cause / de ce qui rendra le champ invisible ou modifiable : un droit, des valeurs… pas de la conséquence front.
L’outil qu’on met en place a beaucoup de champs à remplir (c’est du réglementaire).
Certains champs ne sont pas demandés (donc cachés ou grisés) sous certaines conditions.
J’ai un calcul de complétion au niveau de l’objet (% de champs remplis / % de champs à remplir, donc non grisés / cachés). C’est une simple boucle sur les champs qui exclut donc ce qui n’est pas updatable ou visible. Si je dois recoder ces conditions dans le back, ça va alourdir le code et la maintenance de l’outil car deux endroits à mettre à jour à chaque fois.
Ok je vois,
Si la contrainte doit s’appliquer en back, il faut donc réussir à remettre le champ en “visible en liste” à la fin du search qui boucle sur les lignes = pour ne pas dépendre de la dernière ligne.
Donc dans le postSearch, qui vient avant que les méta-data de l’objet ne soient générés (donc la colonne visible).