Bonjour,
Je viens d’installer la 6.3.6 et j’ai toujours le problème de visibilité en liste mentionné ici Contrainte de visibilité en liste - #10
Dernière ligne ne valide pas la contrainte : colonne cachée
Dernière ligne valide la contrainte : colonne affichée
Merci d’avance pour votre aide !
Emmanuelle
[Platform]
Status=OK
Version=6.3.6
Variant=full
BuiltOn=2026-03-12 16:20
Bonjour,
Quelle est la définition de la contrainte ?
Comme indiqué dans le post précédent, elle ne peut être active qu’en front sinon elle agira en back sur toute la colonne.
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.
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.
public Boolean isFieldEligibleForCompletion(ObjectField f)
{
return !f.isTechnicalField() && !f.isReferenced() && !f.isInternalRowId() && f.getType() != ObjectField.TYPE_ID && f.getVisibility() != ObjectField.VIS_HIDDEN && f.getFieldArea().isVisible() && f.isUpdatable();
}
for (ObjectField f : fs)
{
if (isFieldEligibleForCompletion(f) && !isCompletionField(f))
{
total++;
if (!f.isEmpty())
cpl++;
}
}
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).
getField("x").setVisibility(ObjectField.VIS_BOTH);
Désolée François je ne dois pas bien m’y prendre, ça ne fonctionne pas chez moi
@Override
public List<String[]> postSearch(List<String[]> rows) {
AppLog.info("postSearch ", getGrant());
getField("cdpFinpdtcrLoanToValueVnWaiverProof").setVisibility(ObjectField.VIS_BOTH);
return super.postSearch(rows);
}
Les metadata
Effectivement après vérification, ce hook passe avant les contraintes dans le service search.
Pour simplifier ça fait ceci en back :
obj.getCount() pour cacluler le nombre de pagesobj.search(paginé)data+meta avec application des contraintes back par lignemetadata de l’objet sans réappliquer de contraintes back / pour préserver l’objet modifié par les hooks précédentsLe 4) était fait en premier en V5.3 mais le problème qu’on a rencontré en V6 est que si un hook pre/postSearch ou pre/postSelect modifie une définition de l’objet, ce n’était pas émis vers le front. et aussi l’apparition de 2 nouveaux hooks pre/postObjectSearch pour les instances REF_SELECT et DATAMAP qui ont souvent des comportements particuliers (popup object/ref picker).
Bref pas simple de trouver une combine dans ton cas car réappliquer des contraintes (ou un initList) n’a pas de sens après le search car les hooks JAVA doivent toujours passer “par dessus/après” les contraintes. Il manque un truc.
La seule solution/évolution serait de rappeler le postSearch entre le 3) et le 4) ou plutôt d’avoir un nouveau hook final postSearch() sans records pour pas tout mélanger car le postSearch(rows) sert plutôt aux champs calculés.
Voilà une solution qui fonctionne :
Les meta-data de l’objet, lors du search, évaluent d’autres contraintes pour savoir si l’utilisateur peut créer/copier un record. Donc une solution simple est d’ajouter une contrainte en contexte CREATE qui passera après ta contrainte true qui s’applique tout le temps :
Contrainte C1:
Front + Back, ordre 10, expression = truedemoSupPhone visible = [VALUE:demoSupName].equals("SUP")Contrainte C2:
Back, ordre 20, expression = [CONTEXT:CREATE]demoSupPhone visible = trueMerci beaucoup d’avoir pris le temps de chercher, en effet ça règle mon problème.
En parallèle, j’ai tenté de surcharger les metadata après le search mais je n’ai pas trouvé de hook adéquat (beforeLoad : trop tôt, preload : trop tard …).
Mais est-ce obligatoire d’avoir les metadata écrasées par celles de la dernière ligne ? Car je me dis que ça peut causer d’autres comportement non attendus.
En tout cas je vais mettre en place cette contrainte sur tous mes objets, encore merci et bonne journée !
On ne peut pas présager de ce que font les hooks au niveau de l’objet lui-même, des zones, des actions et/ou des fields… C’est la même chose si un “initUpdate” ne remet pas le champ visible en spécifiant que lorsqu’il est masqué.
L’objet reste toujours dans l’état que les hooks/contraintes l’ont modifié. Le problème ici est qu’il n’y pas d’appel “final” à cette contrainte en contexte “LIST” et sans “row” pour le réinitialiser. L’expression traite des données de ligne alors qu’ici il n’en a pas, c’est très ambigüe.
Une piste serait de créer un [CONTEXT:ROW] différent de [CONTEXT:LIST]
[CONTEXT:LIST] agisse sur les lignes ET la liste avec ce problème[CONTEXT:ROW] uniquement sur les lignes pour mettre des règles par ligne/valeursOu alors moins impactant et dissocié des contraintes pour rester dans un cadre plus global, créer des hooks pre/postMetadata(context, row ou null) appelé à chaque génération back des metadata.
Ca me semble une bonne idée pour y mettre la visibilité par défaut en contexte LIST et sans row.
Je serais très intéressée par ces hooks dans une future version en effet !
Et les CONTEXT également, même si je comprends que ce n’est pas trivial à mettre en place.
Les 2 hooks pre/postMetadata(context, row) seront livrés en 6.3.7.
Cela pourra remplacer la contrainte C2 en remettant la colonne visible :
public void postMetadata(int context, String[] row) {
if (context==ObjectDB.CONTEXT_LIST && row==null) {
getField("demoSupPhone").setVisibility(ObjectField.VIS_BOTH);
}
}