Implémentation correction contrainte de visibilité en liste

Request description

Bonjour,

Je n’arrive pas à implémenter le hook postMetadata pour mon souci de contrainte de visibilité en liste.

Sur le même cas :

	public void postMetadata(int context, String[] row) {
    if (context==ObjectDB.CONTEXT_LIST && row==null) {
    	
    	AppLog.info("postMetadata 1 " + getField("demoSupPhone").getVisibility(), getGrant());

        getField("demoSupPhone").setVisibility(ObjectField.VIS_BOTH);
        
        AppLog.info("postMetadata 2 " + getField("demoSupPhone").getVisibility(), getGrant());

    }

Dernière ligne = ‘SUP’, la colonne s’affiche

Dernière ligne != ‘SUP’, la colonne disparaît

Dans les logs je vois que j’entre bien dans la condition
image

Mais ça n’est pas appliqué (ou écrasé ?) sur les métadata

Pouvez-vous m’aider à la mettre en place ?

Merci à vous !
Emmanuelle

[Platform]
Status=OK
Version=6.3.7
Variant=full
BuiltOn=2026-04-03 09:42

Bonjour,

Ces hooks sont appelés :

  • au moment d’exporter en JSON chaque ligne de la liste (row not null)
  • puis la définition de l’objet (row is null)

Il faut donc plutôt utiliser le hook preMetadata en testant row==null pour remettre le champ en visible avant d’exporter sa définition.

Merci de ta réponse rapide, cela ne fonctionne pas non plus, j’ai toujours visible = 0 dans les metadata.
Aussi, le search passe après le getMetadata, je ne sais pas si ça change quelque chose ?

	public void preMetadata(int context, String[] row) {
	    if (context==ObjectDB.CONTEXT_LIST && row==null) {
	    	
	    	AppLog.info("preMetadata 1 : " + getField("demoSupPhone").getVisibility(), getGrant());
	
	        getField("demoSupPhone").setVisibility(ObjectField.VIS_BOTH);
	        
	        AppLog.info("preMetadata 2 : " + getField("demoSupPhone").getVisibility(), getGrant());
	
	    }
    
	    super.preMetadata(context, row);
	}

image

Bizarre les tests fonctionnaient. On va en refaire, il y a peut être un truc qui a changé depuis.

C’est un objet normal ?
pas un objet select ou service ?
group-by fields ?

Au premier usage d’un objet (nom d’instance), le call metadata est demandé par le front pour récupérer la définition de l’objet et ses ressources (contraintes, script, class, styles…). Ce call n’est plus sensé se produire ensuite, enfin tant que l’instance d’objet est en cache front.

Ensuite, chaque search ramène les données et les métadata par ligne et globalement.
Le displayList utilise le obj.metadata global + displayRow les meta de chaque ligne obj.list[i].meta en surcharge des globales.

Il faudrait regarder le contenu des meta reçues au niveau du call search lui-même.

J’ai fait le test sur DemoSupplier avec le champ Phone en VIS_BOTH. J’ajoute la contrainte en PJ
DemoSupplier-C1 (1).xml (2.1 KB)

Dans le search, j’ai aussi visible = 0.

Suite à des tests en pas-à-pas, lors de l’export des meta-data, il y a des hook/contraintes qui sont appelées avec différents contextes.

Notamment le isCreateEnable : la contrainte s’exécute car la condition est true sans contexte, et le champ “Phone” repasse en masqué puisque le nom est vide.

En ajoutant à la suite de la 1ere contrainte, une autre contrainte en condition [CONTEXT:CREATE] pour mettre le Phone en visible en création, ça fonctionne.

Par contre, ce n’est pas normal que la contrainte impactant un Field s’exécute alors que le test concerne la propriété de création de l’objet. C’est comme ça depuis l’origine, mais ça me semble plutôt être un bug.

Je pense que la création d’une 2ème contrainte est la solution proposée ici, effectivement ça fonctionnait chez moi, mais ça m’oblige à dupliquer toutes mes contraintes (j’en ai vraiment beaucoup :sweat_smile:)

Y aurait-il moyen de modifier l’expression de la contrainte pour que le isCreateEnable ne s’exécute pas ? Ou faire quelque chose dans le hook en lui-même ?

Il faudrait essayer quelque chose comme :

visible = [CONTEXT:CREATE] || [FIELD:x]=="y"

On va corriger pour ne pas appliquer les impacts Field/Target pour savoir si l’objet peut être créé dans les métadata = tous les flags issus des contraintes/isXXXEnable :
metadata.create|copy|update|delete

Alors je vais attendre le patch, on est encore en phase de développement.
Je garde ton option comme roue de secours pour plus tard :slight_smile:

Ok désolé je n’avais pas vu ce cas d’usage la dernière fois.

isCreateEnable n’est pas vide par défaut, il lance entre autre les contraintes pour tester un impact sur la propriété de “création” de l’objet :

public boolean isCreateEnable() {
	return !isReadOnly() && checkCreateConstraints() && checkCreateVisibilities();
}

checkCreateConstraints appelle ObjectDB.checkObjectPropConstraints dans un contexte de creation mais il avait des impacts trop larges, il ne doit agir/exécuter que les contraintes impactant les propriétés de l’objet.

On s’en sert très rarement car ce fonctionnement/bug date d’avant la V4…
Ce sera corrigé 6.3.8.