Mais comme on peut le voir sur la capture je n’ai plus accès à l’ancre de recherche et il n’est pas possible de supprimer le filtre appliqué (en l’occurrence dans notre cas sur la statut).
Etait-ce la bonne manière de faire ? Y-a-t-il un moyen de faire apparaître cette ancre ?
Technical information
Instance /health
Simplicité version6.2.12
Simplicité logs
---paste the content of the **relevant** server-side logs---
Browser logs
---paste content of the **relevant** browser-side logs---
Other relevant information
----E.g. type of deployment, browser vendor and version, etc.----
Les filtres sont conçus pour être dynamiques = à la main des utilisateurs (à part les filtres de vue de home page mais ce n’est visiblement pas le cas ici)
Les forcer dans un hook n’est en général pas une bonne approche, à fortiori si vous voulez ensuite laisser l’utilisateur pouvoir les supprimer
S’il s’agit de filtrage statique (que vous ne voulez pas voir et valables tout le temps) il faut plutôt utiliser une “(default/additional) search spec” SQL (setSearchSpec/setDefaultSearchSpec/setAdditonalSearchSpec, typiquement dans le cas d’héritages et/ou de règles liés aux droits du user connecté
Il faut que votre objet possède l’option de recherche correspondante.
Comment est il paramétré à ce niveau ?
Les filtres peuvent se retirer depuis le header de la liste avec la petite croix du badge.
Mais s’il est remis par code (preSearch ou searchSpec), il reviendra toujours.
Vous pouvez mettre un filtre fixe par code au lieu d’une search-spec. Ca enlèvera la croix et l’accès en mise à jour au filtre.
getField("x").setFilter("in ('STA','IAG','IAN')"); getField("x").setFilterFixed(ObjectField.FIXED_FILTER_READ);
pour l’afficher sans pouvoir le supprimer en front.
Une search-spec est purement back, ce n’est pas un filtre utilisateur, mais un filtre métier. L’objet devra porter un nom qui signifie ce qu’il affiche (les AO de type STA/IAG/IAN) sinon ce sera confusant pour l’utilisateur.
Si votre instance est une instance Home, le filtrage par colonne est actif par défaut et sans accès aux autres modes de recherche (usage en bannette préfiltré, avec possibilité de sur-filtrer en colonne), il faudra utiliser une autre instance de votre objet.
En 6.3, le fonctionnement à été revu pour donner accès à la recherche par dialogue même sur un instance Home.
Ce dernier a bien le fonctionnement voulu avec l’ancre pour la recherche etc..
Peut-être existe-t-il un objet dont je n’ai pas connaissance qui me permettrait de réaliser ce que je veux, à savoir dans un domaine avoir un lien qui me ramène vers l’objet IAOAppelOffres avec le filtre présélectionné ?
Oui réutiliser un objet pour afficher une bannette filtrée fait sens (mes dossiers, les dossier en retard…).
En général, on crée une Vue avec un item de recherche d’objet avec le filtrage (statique) voulu.
Et cette vue est mise en accès dans le menu, ou en home page, ou accueil de domaine.
Un autre pattern consiste à passer par un objet externe pour les cas plus spécifiques (faire autre chose sur l’objet, autre que passer des filtres sur l’instance home d’une vue).
Quel est le code de votre objet externe qui “redirige” vers la liste de l’objet ?
Il faut voir vers quelle instance vous allez et avec quels paramètres de displayList, ça peut influencer le mode de recherche accessible.
