Nous utilisons une structure de catégories profonde à deux niveaux (toutes les bibliothèques publiques de notre ville avec leurs succursales individuelles, plus une bibliothèque centrale avec ses propres catégories de premier niveau). Récemment, nous avons eu besoin d’introduire un troisième niveau d’imbrication dans certaines branches de catégories.
Dès qu’une catégorie, n’importe où dans l’arborescence, possède une catégorie petite-fille, la page d’accueil des catégories change son mode d’affichage : au lieu de la grille compacte de boîtes (catégorie parente avec ses enfants directs répertoriés à l’intérieur), toutes les catégories sont affichées sous forme d’une longue liste à une seule colonne. Cela rend la page d’accueil extrêmement longue et difficile à parcourir pour nos ~1 200 utilisateurs du personnel.
Cela semble être régi par la propriété isGrandParent décrite dans ce fil connexe : When you add an additional nesting level, all categories, including child categories, are displayed on the categories page
Ce que nous souhaiterions
Notre option préférée : un moyen de conserver la mise en page standard de la page d’accueil en « boîtes » même lorsqu’une catégorie possède un troisième niveau d’imbrication — par exemple, en ne montrant simplement pas les catégories petites-filles sur la page d’accueil (elles resteraient accessibles via la page de la catégorie parente).
Alternativement, une vue native extensible/réductible pour les catégories ayant des petites-filles directement sur la page d’accueil des catégories, afin que les utilisateurs puissent développer uniquement les branches dont ils ont besoin au lieu d’avoir tout listé à plat.
Pourquoi nous demandons une solution native/officielle
Nous sommes conscients qu’il existe des solutions de contournement via des composants de thème/CSS ou JS (par exemple, en écrasant isGrandParent via modifyClass) discutées dans l’ancien fil lié ci-dessus. Nous préférerions ne pas emprunter cette voie : nous n’avons pas une expertise approfondie en front-end en interne, et nous craignons des effets secondaires inattendus ou des dysfonctionnements lors des mises à jour futures de Discourse si nous écrasons nous-mêmes la logique de rendu principale. Un paramètre pris en charge ou une option officielle serait beaucoup plus sûr pour nous à maintenir à long terme.
Nous sommes conscients que Discourse ne recommande pas officiellement une imbrication profonde, mais pour notre structure organisationnelle (plusieurs institutions, chacune avec plusieurs sites physiques, ayant chacun besoin de leur propre espace), ce n’est pas optionnel pour nous.
Un moyen pris en charge de contrôler l’affichage de la page d’accueil pour ces cas serait très utile et nous sommes sûrs, depuis 2021, qu’il pourrait y avoir besoin d’un 3e niveau caché dans d’autres organisations aussi ?
Captures d’écran jointes : notre mise en page actuelle de la page d’accueil à 2 niveaux
et comment elle se brise actuellement dès qu’un 3e niveau est introduit.
