possible bug : il semble que les préférences d’ordre des colonnes ne soient plus prises en compte dans les vues listes et les exports Excel standard. Le fait de masquer/afficher est par contre bien pris en compte (y compris dans l’export Excel).
Nous sommes dans le cas le plus simple d’objet avec une dizaine d’attributs sans zonage.
J’ai réinitialisé mes préférences de listes (LIST_PREFS; par l’IHM et pas suppression du paramètre utilisateur) sans succès.
Effectivement, la UI responsive ignoraient les ordres de préférence en liste des objets “mono-zone”.
Et ça a toujours été comme ça… en général on utilise les préférences sur les gros objets et c’est passé inaperçu sur les petits. Ce sera corrigé au prochain build.
Par contre, je ne vois pas de rapport avec l’export Excel qui est purement un traitement back, à vérifier sur quelle instance travaille l’export pour voir si les préférences s’appliquent dans ce contexte. Il y a peut être une régression suite aux optimisation sur la V5 : le traitement est asynchrone pour rendre la main à l’utilisateur et travaille sur une instance dédiée.
Je confirme les exports Excel n’ont jamais utilisé l’ordre des zones ou les préférences, mais l’ordre de l’objet natif (les titres des zones ne sont pas exportées en sur-entête nul part d’ailleurs…).
Donc à ce niveau, c’est un plus un change request qu’une régression ;-)
En effet, je ne sais pas comment j’ai pu avoir l’impression que les préférences d’affichage/masquage des colonnes était effectif dans Excel car j’ai passé mon après-midi dessus sans réussir à faire quoi que ce soit…
Je souhaiterai pouvoir configurer un export Excel standard (pour ne pas me lancer dans une publication Excel ad-hoc) en forçant l’ordre et la visibilité des colonnes…
J’ai pour ce faire implémenté du code dans preExport/postExport permettant de modifier les propriétés (get/set)OrderInObject et (get/set)Visibility des colonnes. En gros, dans le preExport je force les ordres et visibilités de chaque Field et dans le postExport je restaure à l’état initial.
Et bien rien n’y fait, l’export Excel ne tient pas compte des modifications apportées sur les Fields.
En ce qui concerne l’ordre des colonnes, je me suis dit qu’il fallait attendre ton retour mais pour l’affichage/masquage des colonnes, j’ai essayé ObjectField.VIS_HIDDEN et ObjectField.VIS_FORBIDDEN mais ça reste sans effet sur l’export.
J’ai essayé de passer par this.getFields ou this.getGrant().getMainObject(…) mais sans succès.
Il est préférable de rendre cela à la main de l’utilisateur dans les options d’export plutôt que de faire du code, il aura le choix suivant :
Toutes les données de l’objet (i.e. étendu + visible en formulaire)
Les données affichées sur la liste (i.e.étendu + visible en liste)
Avec en plus : respectant mes préférences d’affichage en liste (i.e. préférences + sans les champs étendus)
(Ce besoin sera backporté en V4 pour un autre projet en cours pour début septembre)
Attention : les préférences de liste ne rendent pas exactement les champs “invisibles” (au sens setVisibility false) mais uniquement “étendus en liste” (setListMore true). Du coup, même si l’export travaille en V4 sur la même instance (main), les champs ne sont pas invisibles pour l’export.
Cela étant, il est important de bien comprendre comment les données sont en mémoire pour les modifier à la volée via hook :
Pour la UI, l’ordre des champs est donné au travers des zones : getFieldArea(…).getFields(), zones elles-mêmes ordonnées via la liste des zones getFieldAreas().
Pour l’export, c’est bien l’ordre de la liste getFields() uniquement et les champs visibles partout ou en liste uniquement qui sont exportés.
OrderInObject n’a pas d’incidence : c’est une donnée “statique” qui permet de trier les champs entre eux au chargement de l’objet (en cas d’héritage d’un autre déjà ordonné), ou de mettre à jour l’objet-field identifié par sa position dans l’objet.
En V5 :
Il y a de gros changements structurels en cours pour rendre asynchrone et plus robuste l’export, et laisser la main à l’utilisateur sur son instance front (main, panel…) : l’export se fera désormais sur une instance dédiée préfixée “export_” (avec un petit slider en bas à droite côté front). Du coup si via pre/postExport on agit sur l’instance “main” ça n’aura aucun effet sur l’instance this = “export” .
Bonjour François,
merci beaucoup pour ces apports et ces éclairages (précieux).
J’appuie donc sur le frein avec les deux pieds et je laisse le ticket au frais durant l’été :)
Il reste encore un point qui n’est pas clair pour moi: sera-t-il possible dans le cas du choix “mes préférences d’affichage en liste” dans un contexte connu (à déterminer) de forcer les préférences (visibilité et ordre) selon un pattern d’export spécifique puis des les restaurer après l’export ?
Une autre option (peut-être finalement plus simple) consisterait à procéder par héritage et à reconfigurer dans l’objet héritier l’ordre et la visibilité des champs de l’objet hérité. Est-ce possible ?