Modifier l'ordre d'une liste "initRefSelect" pour mettre en avant certaines lignes

Bonjour,

Nous avons quatre objets liés de la manière suivante :

image

  • L’objet EsatDAAC est lié à une et une seule PUI (EsatPUI)
  • Un prescripteur (EsatPrescripteur) est lié à plusieurs PUI via l’objet EsatPrescripteurPUI (table d’association). Les PUI liées au prescripteur sont ses PUI favorites.

Dans le formulaire de création de EsatDAAC, lorsqu’on choisit une PUI, nous aimerions modifier l’ordre de la liste pour faire remonter en premier les PUI favorites de notre prescripteur connecté.

Pour le moment on modifie l’ordre dans le postSearch() de EsatPUI de la façon suivante :

Mais cela ne fonctionne pas avec la pagination. Si une PUI favorite se trouve en page 2 elle ne remontera pas page 1. Avec cette méthode on met en avant les PUI favorites, s’il y en a, dans la page actuelle sans prendre en compte la présence de PUI favorites dans les pages suivantes.

Auriez-vous une idée pour faire remonter les PUI favorites du prescripteur connecté en prenant en compte la pagination s’il vous plait ?

Merci d’avance,

Florent

[Platform]
Status=OK
Version=5.1.22
BuiltOn=2021-12-29 12:44
Git=release/a4a4aafa93310ec3387ad178ae2001072320c3f3
Encoding=UTF-8
TimeZone=Europe/Paris
SystemDate=2021-12-31 15:11:24

Bonjour,

Plusieurs idées :

  • ajouter une colonne dans votre objet de sélection qui permettrait de voir/pondérer/trier/filtrer le caractère “favori” d’un objet au niveau SQL

  • retirer la pagination sur votre instance si la volumétrie n’est pas énorme, ou limiter le nombre de lignes ramenées ou utiliser des filtres

if (isRefInstance()) {
  setLimit(false); // no pagination on UI
  setSearchLimit(200); // only 200 first rows
}
  • Ajouter tous les favoris sur la première page uniquement dans le postSearch
if (getCurrentPage()==0) {
   rows.add(0, ...)
}
  • surcharger complètement les méthodes getCount et/ou search de l’instance ref pour ramener comme vous voulez ce que vous voulez en fonction de la page sélectionnée.

Pour moi, le plus simple reste de retirer la pagination pour ce genre de besoin de tri spécifique et non SQL, mais il serait préférable d’avoir l’information “favori” en terme d’UX ou d’évolutivité du modèle si c’est possible.

Merci pour ces idées François :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.