Nous souhaitons mettre à disposition la fonctionnalité de modification en masse sur quelques objets auprès des utilisateurs de l’application.
Pour cela, nous avons besoin de mettre à disposition un document traçant tous les objets n’ayant pas pu être mis à jour (pour cause de non-respect des règles fonctionnelles).
Le hook postUpdateAll ne renvoyant rien, pouvez-vous nous indiquer quelles pistes peuvent être envisagées pour mettre un document (txt/pdf/csv) à disposition de l’utilisateur après l’action de mis à jour en masse (il serait préférable que le fichier soit tout de suite proposé à l’utilisateur, sans navigation au préalable).
Outre la remontée d’erreurs, est ce que la fonction standard convient aux utilisateurs sinon ça sert à rien d’avancer cette piste :
Mise à jour en masse mono-objet : donc parmi ses attributs propres + foreign-key (non ramenés en jointure)
Accès à partir de la liste (filtrable) + cases à cocher pour sélectionner les lignes à modifier en masse
Ecran de mise à jour qui liste les zones et les attributs sans templating (ni hook front) où il active par checkbox certains champs à modifier en masse + saisie des valeurs + save
On pourra faire évoluer cette ergonomie si l’objet à 300 attributs, mais pas la rendre paramétrable, comme par exemple choisir uniquement les champs à modifier via une selectbox.
Si cette base est acquise, on pourra regarder à rendre le postUpdateAll plus riche et/ou directement remonter un rapport d’erreur à la UI nativement.
avoir une liste de messages en paramètre pour chaque ligne en erreur : c’est à dire récupérer un tableau avec le résultat des validate+save de chaque ligne en fin de processus
et que le service de mise à jour en masse puisse afficher ce rapport d’erreur complet
La liste d’erreurs est un besoin qui a déjà été formulé, on peut très bien afficher le rapport d’erreur sans besoin de passer par le hook = remplacer le toast actuel qui indique le nb de lignes OK / nb total par un rapport PDF par exemple s’il y a des erreurs uniquement.
A date, la UI affiche un popup avec les erreurs distinctes s’il y en a, en restant sur la page de mise à jour en masse.
Ce n’est pas un export de toutes le lignes KO car potentiellement énorme si un champ saisi est non conforme, il le sera pour toutes les lignes. Il suffit juste de dire que le champ X est non conforme une seule fois.
Si les règles sont trop complexes ce n’est pas ce genre d’UX qu’il faudra.
Expliquer 1000 regles de gestion sur 1000 lignes rejetées n’est pas ergonomique, c’est un traitement d’import avec log d’erreur qu’il faudra faire.
La mise à jour en masse pour qu’elle reste user-friendly sert à faire des opérations simples sans trop de risques d’erreur (erreur de format / saisie d’une date par exemple), mais pas appliquer des process métier complexes en masse avec une multitude de rejets possibles qu’il sera impossible de restituer à l’écran de façon unitaire par ligne.