Depuis la vue en liste des “CRM lié à la durée de décaissement”, je veux vérifier le message d’erreur lorsque je tente de supprimer des lignes qui sont référencées dans des concours.
Si j’en sélectionne une seule, j’ai bien le message d’erreur. Mais si je clique sur Tout sélectionner, puis que je clique sur Supprimer en masse, tout mon référentiel est vidé sur l’IHM. Dans les logs du navigateur j’ai le message suivant :
Si je reviens sur mon référentiel, ou si je rafraichis la page, alors toutes les données sont encore là (ce qui est normal).
J’ai un autre référentiel similaire à celui-ci, et j’ai bien le message d’erreur lorsque j’effectue une suppression en masse. Je n’ai pas de Ressources (js) dans le référentiel qui n’affiche pas le message d’erreur lors de la suppression en masse.
Merci d’avance pour votre aide,
Alexandre
PS. : Je ne sais pas si ça peut aider, mais en front, si je suis les logs de mon navigateur, c’est la ligne suivante qui pose problème " $(msgRow[i]).each(function() {". Si je print msgRow[i], alors je vois que c’est une chaîne de caractères : “Cet objet est encore référencé dans: Concours”.
Ca semble juste un problème d’affichage sur la UI au retour en erreur du back, rien n’est supprimé physiquement. Le back ne doit pas renvoyer un tableau d’erreurs = 1 rejet par ligne non supprimée.
On va renforcer le code pour gérer ce cas.
Mon mode opératoire est assez nominal. Je vais sur la vue en liste, je sélectionne toutes les lignes via le bouton Tout sélectionner en haut à gauche. Puis dans le menu burger, je clique sur Supprimer en masse.
J’ai ajouté des liens entre les concours et l’autre référentiel qui marchait ce matin, pour avoir la même volumétrie qu’avec le référentiel qui ne fonctionnait pas. Et maintenant, il ne fonctionne plus non plus, il a le même comportement : message d’erreur, et liste vide avant de rafraîchir.
Est-ce possible que le nombre de liens impacte ce comportement ? (J’ai 1600 liens Concours/CRM environ)
1600 liens à supprimer de façon synchrone = il faut penser à créer une action de purge SQL en masse (delete … where …) qui ira plus vite qu’une boucle de 1600 select/delete de row_id.
Vous êtes dans un cas au limite assez moyen en terme d’UX et qui ne doit pas être bien géré (timeout ou impossible d’afficher 1600 erreurs…), j’ai testé le “select all” et ça fonctionne correctement pour un volume “normal” de lignes.
Merci François. Effectivement, d’ailleurs, je ne crois pas qu’il y ait de réel besoin, les utilisateurs sont juste tombés sur ce comportement par hasard, en éprouvant l’outil. Nous allons communiquer votre retour au client.