Contrainte de visibilité en liste

Request description

Bonjour,
Désolée encore un souci avec les contraintes :grimacing:
On dirait que la visibilité de toute la colonne en liste est définie par celle du champ pour la dernière ligne de la liste.
J’ai reproduit sur la Demo avec un cas simple :

  • créer une contrainte front + back avec un impact de visibilité sur un champ
  • le champ doit être visible au moins en liste

La contrainte en XML (il faut passer le champ Phone en visibilité Always)
Constraint.xml (1.4 KB)

Si la dernière liste de la liste ne remplit pas la condition, la colonne est masquée

J’ajoute une ligne qui remplit la condition, la colonne apparaît

J’ajoute une ligne qui de nouveau ne remplit pas la condition, la colonne disparaît

Y a-t-il un moyen pour moi de debugger les contraintes en back ? J’ai du mal à comprendre ce qu’il se passe :-/

[Platform]
Status=OK
Version=6.3.5
BuiltOn=2026-02-20 11:40

Bonjour Emmanuelle,

Merci pour ton retour, c’est étrange en effet on va regarder.

Théoriquement :

  • chaque ligne en front porte ses data + meta-data / donc chacune avec le champ visible ou masqué.
  • si un champ est masqué dynamiquement, ça ne signifie pas que toute la colonne sera masquée, c’est juste sa cellule qui doit être masquée pour laisser les autres cellules visibles.
1 Like

En fait cette contrainte étant à true fait double emplois, elle s’applique à 2 niveaux en back :

  • elle dit que la colonne est masquée au niveau de l’objet (meta-data de l’objet, les champs sont vides donc ne remplissent pas la condition)
  • elle dit que chaque cellule est visible que si la valeur est “SUP” (meta-data de chaque ligne)

La dernière ligne agira sur toute la colonne.

  • Il faut parvenir à laisser le champ visible en liste
  • Et ne masquer la valeur que sur chaque ligne

En mettant uniquement la contrainte en front

  • la colonne reste visible en back et en front (au niveau de l’objet)
  • mais la cellule reste visible même si la contrainte est “fausse”
  • alors que la champ est bien masquée dans le formulaire.

Je passe en anomalie ce point.

1 Like

Ce cas pose aussi la question :

  • de vider la cellule si le champ est VIS_HIDDEN ?
  • ou bien de juste la masquer (comme pour le champ hidden dans le formulaire) ?

Car au debugger on pourra toujours consulter la valeur :

Si la règle de gestion est de vraiment rendre inaccessible la valeur, il sera préférable de passer le champ en VIS_FORBIDDEN pour ne jamais accéder à la valeur en front.

Il faut donc que ce champ n’ait pas d’impacts sur d’autres champs en front : la UI le passe juste en hidden visuellement, mais les colonnes sont toujours valorisées pour l’edit-list par exemple.

1 Like

Merci beaucoup pour ton retour rapide et pour tes explications sur le fonctionnement.
Dans mon cas il s’agit bien de simplement masquer le champ (et d’ailleurs, éventuellement retrouver la valeur mise précédemment si on change la condition, car il peut s’agir d’une erreur)

On va livrer ce changement dans la 6.3.6.

Il n’existe pas de contexte CONTEXT:ROW et du coup même en scopant la contrainte en CONTEXT:LIST ça reste compliqué pour dire si on veut masquer toute la colonne ou juste une valeur de ligne sous condition.

Il faudra juste passer le contrainte en “front” pour que le champ reste visible globalement sur l’objet pour voir la colonne. Ensuite la contrainte front s’appliquera bien sur chaque ligne avec les meta-data de la ligne. Je n’ai pas trouvé d’autre façon de faire .

Pour ma part je ne vois pas de cas d’usage où on voudrait masquer toute la colonne dynamiquement. Merci beaucoup pour le correctif rapide !

This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.