Pas de load des metadata à l'initUpdate pour une pillbox

Support
1

Request description

Bonjour,

Je viens d’installer la dernière image et j’ai malheureusement encore un souci avec les pillbox :grimacing:

Quand j’affiche mon objet en liste, j’ai bien un get sur les metadata des pillbox pour chaque ligne.
Mais quand je clique sur une ligne, le get n’est pas réeffectué sur cette dernière, ce qui fait que je travaille avec les metadata de la dernière ligne de la liste.

Au chargement de la liste (12 lignes)

image
image1234×514 95.8 KB

La dernière ligne est à Draft, ce qui veut dire que j’ai le droit de Create sur les pillbox (codé dans le isCreateEnable)

image
image1087×175 5.3 KB

image
image1764×174 4.1 KB

Jusqu’ici c’est normal, mais si je clique sur une autre ligne en Validated (pas de droits de Create sur les pillbox), le get n’est pas refait, j’ai donc encore les droits.

image
image838×192 7.77 KB

(difficile de montrer l’absence de quelque chose, mais ici je suppose que je devrais avoir une nouvelle ligne)

image
image1245×546 104 KB

image
image1636×192 8.51 KB

En analysant, je vois qu’à cet endroit, obj.metadata.context est égal à params.context, ce qui débraye le passage dans getMetaData.

obj && (!obj.isLoaded() || (params.context && (obj.metadata.context != params.context || params.context == $app.CONTEXT_REFSELECT))) ? obj.getMetaData(params).then(set) : set();

En mettant ceci avant le chargement de ma ligne, j’arrive à contourner le problème, mais j’avoue que je ne comprends pas trop ce que je fais et quels seraient les impacts.

$app._businessObjectsCache["RciFormApiDomApp:panel_ajax_RciFormApiDomApp_rciFormApiDomAppFormApiId"].metadata.context = null;

Je suis donc preneuse de conseils ! Et désolée pour ce nouveau souci “pillbox” …

Merci !
Emmanuelle

[Platform]
Status=OK
Version=6.2.19
BuiltOn=2025-12-05 11:56

2

Le (re)chargement des metadata est assez complexe pour rester performant.

Quand le front instancie un objet getUIObject, il charge ses metadata la première fois, et ensuite si le contexte de l’instance a changé. On avait forcé un rechargement pour les REFSELECT car l’objet peut souvent dépendre du parent et il faut repasser par l’initRefSelect systématiquement et ce AVANT d’afficher la liste qui demandera également des metadata actualisées en retour.

Car les metadata sont aussi actualisés à la demande de certains appels get/save… avec le paramètre metadata: true.

J’ai du mal à voir de quel objet/instance/contexte on parle ici ? un panel dans quel contexte ?
Quel est le (pseudo-)code du isCreateEnable ?

afin de reproduire ton cas… pour améliorer la règle de rechargement.

3

Merci pour tes explications !

Voici deux modes opératoires, je ne sais pas s’ils sont liés.

Paramétrage :

  • un objet A avec un champ statut
  • un objet lié N,N avec isCreateEnable = Oui si A est en Draft, non sinon

Cas 1

  • afficher A en liste avec dernière instance de la liste = DRAFT

image
image708×664 25.1 KB

  • cliquer sur n’importe quelle ligne de A : la création en pillbox de N,N est possible, même si le statut de A n’est pas Draft

image
image1324×1092 47.5 KB

  • F5 puis afficher A en liste avec dernière instance de la liste != DRAFT

image
image685×598 20.7 KB

Cas 2

  • même paramétrage, mais également isCreateEnable sur la N,N = Oui si A = new
  • faire une copie d’une ligne de A
  • la création n’est pas autorisée alors que le parent copié de la pillbox est new

image
image1680×1451 139 KB

  • dans les logs, je vois que getParentObject renvoie le parent source de la copie et non le nouveau qui est new

N’hésite pas si je peux ajouter des informations, un grand merci pour ton aide

Emmanuelle

4

Le cas de tester le parent dans le isCreateEnable n’était pas connu jusqu’ici. C’était plutôt sur le initRefSelect pour sélectionner une référence.

J’ai pu reproduire le cas 1, et effectivement ton analyse était juste.
L’instance panel (N,N de la pillbox) ne considère pas avoir changée de contexte (car toujours en PANELLIST) et les meta-data contenant le flag create issu du isCreateEnable sont donc figés au dernier appel de la liste.

On va revoir la règle pour recharger les meta s’il y a présence d’un parent object afin de corriger tous les cas possibles de métadata influencée par un objet père (ref select, panel, pillbox, datamap select…).

Je regarde le cas 2…

5

Ca semble aussi corriger le cas 2.
Voici le code utilisé pour tester dans l’objet N,N de la pillbox :

@Override
public boolean isCreateEnable() {
	ObjectDB p = getParentObject();
	if (p!=null) {
		String status = p.getFieldValue("xxx");
		AppLog.info("status="+status + " id=" + p.getRowId() + " new="+p.isNew());
		return "DRAFT".equals(status) || p.isNew();
	}
    return true;
}
  • En création et en recopie du père : p.isNew() est vrai et p.getRowId() = “0”, et on accède à la création en pillbox
  • idem en mise à jour d’un parent en “DRAFT”

On va livrer le correctif.