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
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.
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.
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).
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 :
