Sur une version 4.0 nous avons deux anomalies sur la navigation Suivant/précédent entre items.
Premier point constaté:
Cette anomalie se produit sur des objets ayant un lien récursif…
Je l’ai reproduit sur mon environnement de formation (formation2) dans le menu Gestion des demandes > Demande
Mon objet Demande (MIG18-002) possède un lien vers une demande parente (MIG18-003).
Si je visualise ma demande parente (MIG18-003) qui possède donc une demande liée (MIG18-002) et que je fais Suivant ou précédent je me retrouve sur un formulaire vide.
Cela ne se reproduit pas sur une demande n’ayant pas de demandes liées et c’est constaté que sur la version Desktop. En version mobile cela fonctionne.
Deuxième point constaté:
Ce deuxième point arrive régulièrement mais pas systématiquement toutefois voici le scénario qui nous a montré l’anomalie plusieurs fois.
(Toujours sur mon environnement de formation) je vais dans “Projet” et je sélectionne le projet “MIG2018”.
Dans l’onglet Demande j’ouvre la dernière demande de la page (MIG18-006) puis je fais “Suivant”. La demande qui est affichée n’est pas la suivante dans le tableau (MIG18-001) mais la demande MIG18-021.
Un autre cas: en ouvrant la MIG18-001 et en faisant précédent j’ai la MIG18-020 au lieu de la MIG18-006.
Ceci n’est qu’un exemple mais sur notre application nous avons pu constater que la demande affichée en faisant Suivant / Précédent n’appartient parfois pas au projet sur lequel nous sommes et donc à la liste de départ, ce qui est encore plus problématique.
Ce deuxième problème arrive quelque soit le mode: desktop ou responsive.
En espérant que vous trouverez une explication au moins à ce 2e point que nous ne pouvons corriger en forçant la version responsive.
Merci d’avance.
Existe-t-il un ordre de tri déterministe sur les champs de l’objet ?
Si l’objet n’a pas de tri sur les champs, le select fait ce qui veut au changement de page.
Si le tri est partiel (que sur un champ non clé de l’objet), rien ne garantit non plus l’ordre entre 2 pages successives.
Pour la perte de filtre entre 2 pages, avez vous du code de type resetFilters dans les hooks ?
Un onglet positionne un filtre sur la foreign-key vers le row_id du parent, il ne faut pas le retirer par code ou par contrainte.
Je m’attendais à ce que je retrouve ce tri autant dans les listes que par navigation suivant/précédent. Après comme je l’ai indiqué, le plus gênant c’est qu’il nous est arrivé qu’il nous affiche une demande qui n’était pas dans la liste des demandes du projet.
Je n’ai pas de resetFilters dans les hooks sur cet objet.
Le context parent était effectivement perdu dans certain usage sur changement de page lors d’une navigation depuis le formulaire. C’est corrigé sur la branche master.
Par contre sur le tri, je ne vois aucun problème. normalement le moteur force un order by sur le row_id (en plus du tri sur les champs) garantissant un tri déterministe entre les pages (même si aucun tri utilisateur n’est spécifié).
Vous pouvez activer les traces SQL depuis le script de l’objet pour voir l’order by généré et vérifier la requête dans les logs.