J’ai l’impression que c’est un problème d’ordre d’écriture dans le fichier JS, car les deux autres classes héritées apparaîssent après celle du père et n’ont pas l’erreur.
Quel est le critère de tri des classes dans le fichier ?
L’algo parcourt tous les objets habilités via les héritages JAVA pour exporter les CLASS front.
Est ce que les objets Java héritent bien de la même façon que tes objets front ? Et l’utilisateur est bien habilité aux 3 objets + l’objet parent ?
Il doit y avoir un problème dans l’algo qui parcourt les objets pour ne pas exporter 3 fois le parent mais du coup ça inverse peut être l’ordre.
On va regarder.
Oui les 3 objets Java héritent de la même façon que les objets JS CLASS.
Bizarrement, je n’avais d’habilitation sur aucun des objets mais j’y accédais quand même, peut-être parce qu’il s’agit d’objets SELECT ? Dans le doute, j’ai ajouté les droits Read et même résultat.
Quelques spécificités :
mes objets héritent via le code (extends) mais pas via le paramétrage (Extend of logical name est vide)
le souci se produit à partir du 3ème objet, si j’en ajoute un 4ème, l’erreur se déplace sur ce dernier, mais si je ne garde que les deux premiers, je n’ai plus le souci
j’ai créé le 3ème objet par export / import XML du précédent (je sais c’est pas bien), est-ce que ça pourrait jouer ?
Y a-t-il des traces que je pourrais mettre quelque part pour avoir plus d’infos ?
A la relecture, l’algo exporte bien pour chaque objet l’ordre topologique, des parents aux enfants.
L’algo se base sur les getObjectLocation(name) construit à partir de la définition des objets donc de l’héritage déclaré dans l’object internal (et donc pas issu du code java ou js).
Sinon si tu ne veux pas d’héritage fonctionnel mais que technique, il faudra essayer de déclarer la classe JS parente comme un shared script / JS partagé.
D’accord, je vais mettre en place l’héritage sur le paramétrage, ça sera plus simple.
J’attends de vérifier que ça règle mon souci et je clos le ticket
