Tableau croisé ne reconnait pas une adresse lié à 2 niveaux

4.0
Tableau croisé ne reconnait pas une adresse lié à 2 niveaux
0
Tags: #<Tag:0x00007f4a040f2fa8>

#1

Bonjour,
J’ai un tableau croisé pour l’objet « Bail » qui affiche les loyers par ville. Il a été créé depuis un moment et ça fonctionnait bien.

Aujourd’hui, quand je l’ouvre, j’obtiens l’erreur suivante :« Erreur ImmoLease: Field for input name proImmoAddressid.addressCity unknown »

Dans l’objet « Bail » il n’y a qu’une seule adresse, c’est celle du « Bien » qui est lié au « Bail », donc pas d’ambiguïté. En plus, c’est une relation à deux niveaux seulement (Bail=>Bien=> Adresse)

Cependant, j’ai constaté qu’en surchargeant Input/Tag l’attribut d’objet en question, le pb est résolu !

Faut-il dorénavant surcharger la zone «Input/Tag » pour tous les attributs d’objets Adresse dans tous les écrans (nous en avons plus de 60) ? Ou bien seulement quand il y a ambiguïté (plusieurs adresses avec des relations à 3-4 niveau, dans le même écran) ?

Merci.
Abed.


(David AZOULAY) #2

Les input tags surchargés ne servent que si il y a ambiguité


(David AZOULAY) #3

PS: Pour ce qui est du message d’erreur on a constaté une regression suite à l’évolution liée à votre post Une relation à 4 niveaux qui induit ce genre de messages dans certains cas. C’est corrigé et poussé sur la branche master donc ce sera normalement corrigé sur votre instance demain


(François Genestin) #4

60 liens vers adresse, ça sent le problème de modélisation. Votre modèle logique est devenu illisible.

il aurait fallu utiliser un héritage d’un objet commun contenant les fields Adresse et autres champs utilisés partout (nom, date…).
A quoi sert d’avoir une table adresse avec des codes adresses… ? chaque entité aurait pu porter son adresse sans avoir à faire autant de jointure dans tous les sens.


#5

@david, une fois que ce bug sera corrigé demain sur notre instance, Puis-je retirer la surcharge Input dans le cas évoqué dans ce Post ? Et pour la relation à plusieurs niveaux (un autre Post), faut-il la garder ?

@francois, il y a sûrement moyen de faire mieux, mais pour cela, il aurait fallu qu’on soit accompagné dans notre développement. Mais comme vous le savez, c’est encore un sujet en cours de discussion…


(David AZOULAY) #6

Tout contournement mis en place par rapport à une anomalie/regression doit être supprimé à terme (après avoir vérifié que le pb a bien été corrigé dans le cas considéré)


(François Genestin) #7

Alors bon courage en attendant que vos discussions aboutissent…


#8

@david, je confirme que le pb a été corrigé. J’ai retiré tous les inputs. Merci.