Changement de l'ordre des colonnes non pris en compte dans les préférences

Changement de l'ordre des colonnes non pris en compte dans les préférences
0
Tags: #<Tag:0x00007f394c447910>

Bonjour,
nous faisons face à un petit souci. Lors du changement de l’ordre des colonnes dans une liste, via les préférences, nous constatons que visuellement, aucun changement n’est pris en compte. Alors que dans le paramètre “LIST_PREFS” de l’utilisateur, le changement se constate bien.

Remarques:

  • Ce constat n’est fait que pour un certain nombre d’objets appartenant à un même domaine.
  • Aucun message d’erreur n’est constaté dans les logs du socle et même dans ceux du navigateur

Ci-dessous le health du socle

[Platform]
Status=OK
Version=4.0.P23
BuiltOn=2019-06-18 18:07 (revision 39cef9a4e9b0455570c6a61bcb74e76ca23e8bdd)
Encoding=UTF-8
EndpointIP=21.0.9.2
EndpointURL=http://5fd51c135a06:8080
TimeZone=Europe/Paris
SystemDate=2019-06-28 16:07:23

[Application]
ApplicationVersion=4.0
ContextPath=
ContextURL=https://bca.dok-dev.intra.renault.fr
ActiveSessions=6
EnabledUsers=845
TotalUsers=3575
LastLoginDate=2019-06-28 16:01:27

[Server]
ServerInfo=Apache Tomcat/9.0.21
ServerType=WEB
User=root

[OS]
Name=Linux
Architecture=amd64
Version=3.10.0-957.12.2.el7.x86_64
SystemEncoding=UTF-8

[Disk]
DiskFree=356814
DiskUsable=356814
DiskTotal=510726

[JavaVM]
Version=1.8.0_212
Vendor=Oracle Corporation
VMName=OpenJDK 64-Bit Server VM
VMVersion=25.212-b04
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.10 2018 04 09
HeapFree=707568
HeapSize=1089024
HeapMaxSize=2275840
TotalFreeSize=1894384

[Cache]
GrantCache=36
GrantCacheMax=0
GrantCacheRatio=0
ObjectCache=639
ObjectCacheMax=10000
ObjectCacheRatio=6
ProcessCache=4
ProcessCacheMax=10000
ProcessCacheRatio=0

[Database]
Vendor=2
ProductName=MySQL
ProductVersion=5.5.45-log
DriverName=MySQL Connector/J
DriverVersion=mysql-connector-java-8.0.15 (Revision: 79a4336f140499bd22dd07f02b708e163844e3d5)
DBDate=2019-06-28 16:07:23
DBDateOffset=0
DBPatchLevel=P23
UsingBLOBs=true

[Healthcheck]
Date=2019-06-28 16:07:23
ElapsedTime=11

On parle de la UI legacy ou de la UI responsive ?

Il s’agit de "UI responsive "

Si cela fonctionne pour certains objets ce n’est pas un problème socle, mais plutôt un problème de données ou de code spécifique :

  • Avez vous des hooks / du code qui manipule l’ordre des champs (postLoad, initList, preSearch…) ?
  • Que contient le paramètre LIST_PREFS en question ? A-t-il été enregistré par la UI/Simplicité ou à la main ? colonne trop petite pour la taille des préférences ?

Faites un “Reset” des préférences pour remettre l’ordre par défaut, et ressayez.

Bonjour François,

j’ai bien vérifié chaque point: pas de code hook qui manipule les préférences; aucune altération (manuelle ou par code) du paramètre LIST_PREFS; nous avons effectivement essayé de faire un reset des préférences par l’UI => aucun impact visible (le problème persiste).

C’est localisé sur un domaine en particulier, tous le objets de ce domaine sont concernés; les préférences des autres objets dans les autres domaines semblent bien prises en compte…

Est-il possible de configurer un objet/domaine de telle sorte que les préférences ne soient pas modifiables ? (on l’a peut-être fait quelque-part sans nous en souvenir / en avoir conscience) Je n’ai rien retrouvé de tel dans le paramétrage des objets concernés.

Supprimer le paramètre de l’utilisateur directement depuis son formulaire.

Et réessayer. Il n’y a rien de particulier au niveau domaine, ce paramètre concatène bêtement l’ordre de chaque objet (un objet par ligne)

Je pense que vous avez dépassé la taille de cette colonne (clob ou longtext suivant la base).

usp_value est configuré en taille 1000000 donc ce ne doit pas être Simplicité qui tronque, je suspecte plutôt la base (ou le driver) de tronquer (ou d’interdire) une requête trop grosse.

Ca rejoint un de vos autres problèmes de fichier tronqué au save.

Bonsoir François,

il ne s’agit pas de la même base (ici, c’est la BCSI).

Je pense avoir trouvé le facteur commun à ces objets sur lesquelles les préférences ne sont pas bien appliquées et qu’on ne retrouve a priori pas dans les autres sur lesquels les préférences le sont.

En l’occurrence, les objets de ce domaine ont tous un attribut repris plusieurs fois comme attribut d’objet. Cette configuration du modèle a été choisie pour répondre à des besoins qu’Alexandre pourra mieux expliquer que moi. Il se trouve également que la première occurrence de l’attribut concerné est visible et que les autres en le sont pas (propriété non visible forcée au niveau de l’attribut d’objet).

Cette configuration peut-elle être à l’origine de la non prise en compte des préférences?

NB: en legacy, cela ne pose pas de problème (les préférences sont bien prises en compte)

Ok merci pour l’analyse,

Je vais regarder ce cas de champs “en double”, il se peut que le full input (qui permet d’identifier tout attribut par son nom complet en traversant toutes les jointures) ne soit pas bien géré par les préférences.

Je ne reproduis pas le problème avec des champs ramenés 2 fois sur l’objet (avec des chemins différents), les préférences supportent bien les “full input” des champs.

Exemple de ligne dans LIST_PREFS sur l’objet produit (DemoProduct) avec 2 liens vers un nom de fournisseur :

DemoProduct:demoPrdReference,demoPrdPicture,demoPrdStock,DemoProduct_DemoSupplier_fk.demoSupName,demoPrdUnitPrice,demoPrdSupId.demoSupCode,demoPrdSupId.demoSupName:demoPrdDescription

Et après modification des préférences :

DemoProduct:demoPrdReference,demoPrdPicture,demoPrdStock,demoPrdUnitPrice,demoPrdSupId.demoSupName,demoPrdSupId.demoSupCode:demoPrdDescription,DemoProduct_DemoSupplier_fk.demoSupName

Un des nom est passé en champ étendu en liste (après le “:”), l’autre a changé de position avant le code fournisseur.

Il faut donc plus chercher une anomalie de paramétrage de votre objet.

Par exemple sur cette copie d’écran, on voit qq oublis à priori sans gravité :

  • vous ramenez une seconde foreign-key mais pas la clé fonctionnelle qui va avec.
  • en général on spécifie un ordre tri par défaut sur l’objet (simplicité triera par row_id par défaut)
  • il n’y a pas d’ordre de lien sur le FK (il y aura donc un ordre par défaut appliqué)

Il faut nous fournir le paramétrage/code de l’objet complet + le contenu de votre LIST_PREFS qui n’est pas appliqué.