Dans nos cas d’usage, l’attribut LegalTextScope (Importateur / Filiale) détermine la liste liée de LegalTextGeographicalZone.
Cependant, pour certains types de documents, le scope n’est pas affiché et peut donc être vide sans que l’utilisateur puisse le modifier.
Aujourd’hui, cela affiche « Aucun résultat trouvé », et nous devons gérer le cas côté Java pour forcer une liste par défaut (LBC_LIST_COUNTRY).
Java code
String[] confirmFields = {
"lbcConfirmAddCountry",
"lbcConfirmAddGeographicalZone",
"lbcConfirmUpdateCountryMaster"
};
String scope = getFieldValue("LegalTextScope");
if (Tool.isEmpty(scope)) {
// Cas 1 : scope vide → charger la liste LBC_LIST_COUNTRY manuellement
for (String fieldName : confirmFields) {
ObjectField cf = action.getConfirmField(lang, fieldName);
if (cf == null) continue;
ObjectFieldList defaultList = new ObjectFieldList(cf);
defaultList.load(this, "LBC_LIST_COUNTRY", getGrant());
cf.setList(defaultList);
}
} else {
// Cas 2 : scope renseigné → réutiliser la liste liée de LegalTextGeographicalZone
ObjectField geographicalZoneField = getField("LegalTextGeographicalZone");
ObjectFieldList list = (geographicalZoneField != null) ? geographicalZoneField.getList() : null;
for (String fieldName : confirmFields) {
ObjectField cf = action.getConfirmField(lang, fieldName);
if (cf != null) cf.setList(list);
}
}
Cette logique fonctionne, mais elle ajoute une dette technique sur plusieurs attributs liés à cette dépendance, puisqu’il faut gérer manuellement les cas où le scope est vide.
Idem quand il existe un troisième code, qui doit obligatoirement être lié à une liste, même s’il pourrait simplement reprendre la liste par défaut.
Proposition :
Récuperer en standard la liste liée par défaut qui s’appliquera automatiquement quand le code maître est vide ou non défini — à l’image d’une valeur par défaut pour les énumérés simples (Liste de l’attribut visé par défaut).
Je me demandais s’il ne serait pas possible d’envisager une approche un peu plus implicite :
Si aucune correspondance explicite n’est trouvée dans FieldListLink (par exemple quand le code parent est vide ou non existant), le socle pourrait simplement conserver la définition de l’ENUM configurée sur le champ.
Cela permettrait de garder un comportement par défaut cohérent — la liste d’origine reste disponible quand aucun code n’est défini — sans avoir à créer un lien spécifique avec un code NULL.
Ce serait une solution plus légère côté configuration, tout en restant alignée avec le fonctionnement habituel des ENUM simples.
Je comprends mais le soucis avec cette approche est de créer un “breaking change”.
Actuellement, la liste liée est vide tant que rien n’est sélectionné.
En général on met une liste bidon ou une des listes possibles sur le champ lié.
Comment ferait-on pour avoir le comportement actuel ?
De mon point de vue, le code “vide” doit être lié à une liste explicitement ou pas.
Ça marche, je comprends le risque de breaking change, c’est logique de ne pas modifier le comportement par défaut. La proposition nous convient très bien dans ce cadre.
Peut-être qu’à terme, il pourrait être utile d’avoir un petit mécanisme d’audit ou de notification (par exemple dans les logs ou un contrôle d’intégrité) pour signaler les cas où une valeur d’ENUM est manquante dans la liste liée.
L’audit ne peut pas savoir si le fait de ne pas avoir de liste liée est normal ou pas.
Dans un cas général, il est tout à fait normal de ne pas avoir un sous-type associé à chaque type.
Exemple sur un Attribut : le type “Image” n’a pas de recherche possible, il n’y a pas de liste liée pour ce type / recherche.
Il faudrait paramétrer “je sais que c’est vide dans ce cas” pour que l’audit soit passant, mais c’est une autre histoire de faux positif à gérer qq part.
En attendant d’être remplacé par une IA qui fera tout ça très bien, le besoin initial sera livré de façon locale et artisanale en 6.3
