L’édition en liste doit appliquer les règles (initUpdate + pre/postSelect) et les contraintes (back + front) pour chaque attribut de chaque ligne.
Les préférences d’affichages ne sont donc pas appliquées pour éviter tout conflit de règles (du type champ non affiché en préférence mais obligatoire, valeur masquée qui rend modifiable un autre champ affiché…) ce qui bloquerait la saisie globale de chaque ligne.
On peut imaginer une évolution pour au moins appliquer l’ordre préféré des colonnes, mais retirer des colonnes en édition n’a à priori pas sens, ce serait comme les retirer du formulaire de saisie par préférence. En mise à jour, ce n’est pas l’utilisateur qui “impose” ses préférences mais la UI qui affiche les champs visibles en liste (donc prévu par un designer pour fonctionner sans d’éventuels champs manquants au choix du user).
Bonjour @Francois , merci pour ton retour.
Effectivement, c’est logique d’afficher toutes les colonnes, du coup on est preneur de l’évolution pour au moins appliquer l’ordre préféré des colonnes.
Merci d’avance,
Abed.
