Bonjour,
j’arrive après la bataille sur le post Export CSV de l'ensemble des lignes ne fonctionne pas - #11 by Francois
Cela ressemble à un problème que nous avons rencontré sur des objets présentant eux aussi des pillbox en liste : dans notre cas, l’affichage en liste se limitait à une seule ligne et nous avons en effet constaté qu’un filtre était positionné sur le row_id alors que ça n’avait a priori aucun sens métier. On a d’abord pensé à un effet de bord non maîtrisé de notre côté et mis en place un contournement dans les hook initList des objets concernés (resetFilter sur le champ row_id) en attendant de trouver le temps de comprendre ().
Dans l’hypothèse où ce serait bien la même chose, si la résolution pouvait aussi couvrir le cas de l’initList ce serait super
ps: nous sommes encore en Version=4.0.P25 BuiltOn=2021-07-16 10:19 mais on va se mettre à jour asap
Oui, le filtre sur le row_id vient d’un select sur chaque ligne pour que les search des pillbox aient un context getParentObject correct : le link peut avoir un filtre/search-spec avec des champs du parent, les hook du panel instance des accès au parent object… Les pillbox sont des mini-panels d’objets liés et elles doivent respecter les règles comme si on était sur le formulaire de chaque ligne.
Je n’ai pas encore pu comprendre parfaitement pourquoi le “dernier” filtre dans tous les appels asynchrones restait en mémoire en back, alors que dans le code il est bien retiré à la fin de chaque select du parent. En attendant, il faut effectivement le retirer à titre préventif avant de lister quelque chose dans votre cas.
Simplicité peut faire des recherches filtrées sur l’id de type “row_id in (…)” ou autre, donc on ne peut pas forcer un resetFilter en entrée de search ou d’initList dans un cas général. Contrairement à un export qui est celui demandé par l’utilisateur (et donc jamais sur des row_id précis).
On va essayer de trouver la cause de la persistance du filtre sur le row_id en cas de pillbox car c’est là qu’il y a quelque chose à corriger.
Nous retirons donc le filtre dès lors qu’il n’est pas à sa valeur par défaut ‘%’ donc y-compris si il y a un filtre “row_id in (…)” → faut-il modifier notre test pour exclure explicitement ce cas ?
Ce genre de recherche c’est quand par exemple il y a des cases à cocher sur des row_id précis à mettre à jour en masse. Vous n’avez peut être pas besoin de sélection de lignes, sinon il est préférable de faire un test comme suit :
ObjectField id = getRowIdField();
if (id.isFiltered() && !id.getFilter().toLowerCase().startsWith("in"))
id.resetFilter();
Après une descente archéologique dans le contexte d’une recherche en liste, une meilleur gestion de la concurrence d’accès entre toutes les pillboxes a été ajoutée dans toutes les versions. Le problème ne semble plus se produire sur nos cas de tests. Le “row_id” retrouve bien son filtre d’origine (% ou autre).
A tester dans une prochaine livraison sur votre instance.
).