[PROBLEME] Clef technique null

Request description

Bonjour,

Depuis la mise à jour 5.2, lorsque j’enregistre mon objet DdvVoting, j’ai cette erreur :

Je ne comprends pas pourquoi puisque ça fonctionnait avant et que le nom de la décision, le nom de l’équipe, la politique de vote, la condition sont bien ramenés dans le formulaire quand je clique sur la loupe et que je choisis et tous ces champs se base sur la clef technique PossessId.

Dans le preValidate, j’affiche cet ID et il est null alors qu’il ne devrait pas l’être.

AppLog.info("============= Posse ID : " + getFieldValue("ddvVotPossessId"), getGrant());

Voici mon MCD :

Voici la configuration de la clef technique :

Technical information

Instance /health
[Platform]
Status=OK
Version=5.2.2
BuiltOn=2022-04-29 15:38
Git=5.2/a2c69b2ee78658770a248e617730e607252990ca
Encoding=UTF-8
EndpointIP=10.201.58.66
EndpointURL=http://siparex-simplicite-dev-777bcd4cfc-dqxdr:8080
TimeZone=Europe/Paris
SystemDate=2022-05-04 11:32:55
Simplicité logs
NA

Même problème dans un autre objet :

C’est pas toute les clefs techniques qui ont ce problème, mais uniquement certaine.

Bonjour,

Est-ce que vous pouvez vérifier que l’attribut ddvVotPossessId est bien clé fonctionelle ?

Merci,

Oui j’ai vérifié.
Voici la configuration :

Je parle du champ de configuration “Clé fonctionnelle”, je ne le vois pas sur votre capture d’écran :slight_smile:

Désolé, j’avais lu trop vite :

Oui c’est une clef fonctionnelle.

Je ne reproduis pas le bug donc on va procéder par élimination.

  • Est-ce que vous avez d’autres attributs d’ordre 10 dans votre objet ?
  • Est-ce que l’attribut est bien présent dans le template de l’objet ?
  • Est-ce que vous avez des erreurs qui remontent lors de l’audit du design ? (Exploitation > Audit du design)

Non, je n’en voit pas d’autre.

Oui, il est bien présent.

Non, le seul Waring que j’ai concernant mon module c’est celui ci :
image

Voici tous les audits :

A part l’erreur, où je ne comprends pas d’où elle vient (puisque c’est un module que nous n’avons jamais touché de notre coté. On savait même pas qu’il existait :slight_smile: ). Les autre Warning, nous étions en train de les fix avant les mise à jour et nous allons continuer de les fix dès que tous nos problèmes sont réglés.

Est-ce que vous pouvez ajouter l’attribut ddvPosPdvId au template ?

Est-ce que dans le template editor vous avez d’autre attributs d’objet non utilisés ?

De plus il est préférable de “grouper” les attributs d’objets ramenenés ensemble, ne serait-ce que pour rendre la lecture du paramétrage plus facile.

Une fois que vos attributs sont tous sur le formulaire, utilisez l’action “Réordonner les attributs”. Vous la trouverez dans le menu burger sur le paramétrage de l’objet métier.

J’ai rajouté tous mes attributs non-utilisé (tous des ID) dans mon formulaire et j’ai réordonné les attributs. J’ai clear le cache et le problème est toujours présent.

On voit bien ci-dessous que je n’ai plus d’attribut non utilisé :

Est-ce que vous pouvez m’envoyer votre module à awheeler@simplicite.fr afin que je teste.

Merci

Vous ne préférez pas plutôt un accès à notre instance ?

Si, c’est encore mieux. Je vous laisse m’envoyer les infos en MP

Je vous ai tout envoyé par email

En réarrangeant les attributs d’objet je n’ai plus l’erreur liée à un id manquant. En revanche il semble y avoir un souci avec la searchSpec dans le postLoad, je vous laisse regarder.

Merci beaucoup,

Vous avez réarrangé les attributs de DdvVoting ou DdvPosseder ?

Parce que j’avais déjà réarrangé les attributs de DdvVoting et ça marchait pas.

Du coups, est-ce que ça signifie que je dois réarrangé tous mes objets métiers pour corriger le problème dans chacun d’eux ?

J’ai quand même pas mal d’objet métier qui ont le même problème. Du coup, j’aimerais comprendre l’exacte raison du problème histoire de ne pas le reproduire dans le futur.

PS : J’essaie de réarranger l’objet DdvResponsibleTeam qui a le même problème et cela ne le corrige pas.
image

Bonjour,

J’ai vu pas mal de clés fonctionnelles ramenées manquantes dans l’audit, les avez vous corrigées ?

Dans une version à jour vous auriez le problème indiqué directement sur la définition de l’objet en plus de l’audit (avec les champs manquants pour identifier l’objet lié).

Si vous ne ramenez pas toute la clé fonctionnelle de vos objets liés via vos FK (et les mettre invisibles sur la UI si besoin), il peut y avoir un problème d’unicité ramené par le picker et typiquement un id forcé à null par le back = contrôle de cohérence/sécurité renforcée dans cette version.

Enfin, il faut que vos champs ramenés soient bien ordonnés à la suite de la FK et pas mélangés au sein de différentes FK vers un même objet par exemple. Bref il faut avoir un paramétrage explicite et plus implicite dans cette version où Simplicité n’a plus à interpréter ce que le designer à voulu dire.

Pas encore, mais elles ne concernent pas ce module (ce sont d’autres modules). Nous allons les corriger dès que tout refonctionne.

Oui, j’ai vu et c’est plutôt cool/utile d’ailleurs. Cependant, comme dit plus haut, cela ne concerne pas ce module (pas d’erreur audit sur ce module).

J’avoue ne pas bien comprendre cette partie.

Sauf erreur de ma part, l’ordre semble correcte :

Et tous mes champs ont été ramené dans mon formulaire (mis en invisible sur l’UI).

Du coup, je m’excuse par avance, mais comme ça marche toujours pas, je pense que je n’ai pas bien compris ce que vous appelez “bien ordonnés”.

Vous avez très bien compris.
Du coup pouvez vous vérifier vos champs à partir de l’ordre 2000 car on dirait que ça devrait être en 35… ?
Généralement quand les noms des FK sont différentes Simplicité s’y retrouve, mais si vous ramenez 2 fois une même FK (2 chemins différents dans le modèle) avec des champs mélangés (i.e. non groupés par ordre après chaque FK), Simplicité ne sait plus de quelle jointure il s’agit au runtime.