Propositions d'évolutions sur la recherche UI

Feature request
1

Version

[Platform]
Status=OK
Version=5.3.22
BuiltOn=2023-11-11 10:20

Description

Bonjour,

Deux suggestions qui nous ont été remontées par les utilisateurs :

  • rendre possible la recherche multiple en cas d’objet ramené (exemple : en cas de lien vers les pays Iso Countries, pouvoir cocher plusieurs pays)
  • rendre possible le filtrage sur les champs calculés

Merci,
Emmanuelle

2

Bonjour Emmanuelle,

Merci pour tes propositions qui font sens.

1) cases à cocher sur recherche de références

La recherche multiple sur champ ramené est déjà possible avec une syntaxe par recherche avancée du style :
in ('a','b') ou ='a' or ='b'
not in ('a','b') ou <>'a' and <>'b'

Mais ce n’est pas aussi intuitif pour un utilisateur lambda qu’une liste de cases à cocher des valeurs possibles. C’est potentiellement couteux de faire un select distinct = full scan de la table liée, donc ce sera pas un mode par défaut mais plutôt un nouveau mode de recherche du champ lié, déterminé par le designer qui s’assurera des performances.

2) recherche de valeur de champ calculé non persistant

Quand c’est possible il est préférable de rendre persistant le champ calculé (au preValidate ou preSave), car la base reste bien plus performante pour indexer/filtrer.

Mais s’il est impossible de calculer le valeur autrement qu’à l’affichage, comme un calcul qui dépendrait d’une donnée variable : un taux de change, des droits utilisateurs, le nombre de dossiers du jour…, là il faudra nécessairement que la possibilité de filtrer se fasse :

en SQL : le champ calculé serait à voir comme un morceau de SQL injectable dans le select ou le where standard utilisé par les services count et search paginé. Ca implique de pouvoir retourner une syntaxe SQL au niveau champ calculé.

en Java : en général on calcule le champs non persistant au niveau postSearch il suffirait d’y éliminer également les lignes qui ne matchent pas avec le filtre UI.

Mais comment appliquer le filtre java dans le service select count en base sans ramener/boucler/filtrer sur toute la table/les colonnes en java ? ce serait contre performant.
Là encore, il faut plutôt chercher à surcharger le getCount et le preSearch de l’objet pour y ajouter une searchspec qui traduit le “calcul spécifique + filtre” en SQL.

1 Like