Listes : cherchez dans tout l’entrepôt, pas seulement dans les lignes à l’écran
Le contrat de pagination derrière chaque liste principale, et pourquoi une page vide n’a jamais le droit de mentir sur votre inventory.
Un opérateur tape un numéro de série dans la recherche d’inventory et n’obtient rien. L’asset existe. Il est en page quatorze. La recherche n’a regardé que les vingt-cinq lignes chargées par le navigateur, et l’opérateur croit désormais que l’appareil n’a jamais été reçu. Une demi-heure et un coup de téléphone gênant plus tard, il s’avère que si. Ce mode de défaillance est la raison pour laquelle chaque liste principale de la plateforme suit une seule règle : chercher d’abord, paginer ensuite.
Le contrat
La recherche et les filtres s’appliquent à l’ensemble du jeu de données de la liste avant que la page ne soit choisie. Ce que vous voyez est la tranche courante de tout ce qui correspond, jamais un filtre posé sur une tranche. La liste vous le dit : le total des correspondances, la plage courante, page X sur Y, des sauts directs vers les pages voisines et un sélecteur de taille de page. La taille de page par défaut est un réglage valable pour tout le tenant sous Paramètres > Affichage et listes, une équipe qui préfère cent lignes par page en décide donc une fois, pour tout le monde.
La barre d’adresse se souvient
L’URL porte le texte de recherche, les filtres, le tri, la page et la taille de page. Rafraîchissez, et vous êtes là où vous étiez. Envoyez le lien à un collègue, et il voit le même ensemble de travail. Ouvrez un asset, corrigez son grade, revenez — même page, mêmes filtres, même ordre de lignes. Une liste qui oublie son état à chaque détour est une liste à laquelle plus personne ne fait confiance après une matinée.
Deux sortes de vide
« Aucun enregistrement » et « aucune correspondance » sont deux phrases différentes, et la plateforme dit la bonne. Un tenant qui n’a pas encore reçu un seul asset voit un état vide de première utilisation qui pointe vers le receiving ou un manifeste inbound comme première étape opérationnelle. Un tenant avec dix mille assets et un filtre qui n’en attrape aucun voit un état sans résultat qui l’invite à élargir la recherche. Et un numéro de page au-delà de la fin de la liste — un signet périmé, un lien partagé après un nettoyage — n’a jamais le droit de faire croire que le tenant n’a pas de données. Une page vide est une réponse, pas une accusation.
Les sélecteurs jouent la même règle
Les sélecteurs opérationnels qui ressemblent à une liste de stock — choisir les assets source d’un job de demanufacturing, sélectionner de l’inventory libre pour un outbound order — cherchent dans tous les candidats, pas seulement dans ceux qui tiennent sur le premier écran, et partent de la même taille de page par défaut. Si un sélecteur peut dépasser une poignée d’enregistrements, il se comporte comme une liste, parce que pour la personne au sol, c’en est une.
Les deux exceptions, nommées
Les grands écrans de type flux, comme l’audit trail de l’Activité, utilisent une pagination par curseur — plus récent, plus ancien — en exception explicite, parce qu’un total sur des millions d’events n’est pas la question qu’on y pose. Les petites listes de configuration bornées et entièrement chargées — les formats de palette d’un tenant, ses types de zone — peuvent filtrer dans le navigateur, parce qu’il n’y a rien à manquer sur une page suivante. Tout le reste pagine comme décrit plus haut. Pas de repli silencieux vers « précédent / suivant » là où un vrai total était possible.
Des lignes ouvrables sans souris
Chaque ligne de ces listes est un seul lien nommé vers son détail. Tab se pose sur la ligne, Entrée l’ouvre, et un lecteur d’écran entend le nom du record une fois — « Acme BV, lien » — pas une fois par cellule et pas seulement « lien ». Les actions qui apparaissent quand une souris survole une ligne apparaissent aussi au focus clavier. La liste est la surface de travail de la journée ; elle fonctionne avec la main qui est libre.