Development #28963
révision de la prise en compte de la visibilité des pages dans les menus
0%
Description
La situation aujourd'hui est qu'elle est prise en compte en local mais pas dans le squelette exporté vers les autres applications. C'est une incohérence mille^Wquelques fois signalée (#9182). L'idéal serait sans doute qu'en toute circonstance la visibilité soit prise en compte mais pour un élément aussi majeur que la navigation principale du site, c'est trop galère (ça voudrait en somme dire ne plus avoir de cache de squelette, ou avoir un cache par usager).
Ma proposition est :
- d'afficher dans la navigation du site toutes les pages (sauf celle marquées "exclure de la navigation", bien sûr).
- de par contre prendre en compte la visibilité pour les cellules menu qui seraient présentes dans un squelette exporté (en en forçant le mode de rendu asynchrone).
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Benjamin Dauvergne il y a plus de 5 ans
Je ne suis peut-être pas à jour sur les conditions de visibilité mais il me semblait que c'était uniquement lié aux rôles et donc on pourrait ajouter à skeleton un entête X-Combo-Condition
contenant un json de la forme:
{
"has_roles": [
{
"uuid": "xxx",
"name": "yyy",
},
...
]
}
ce json listera la totalité des rôles pris en compte pour l'affichage, lors de l'accès au cache on vérifiera que ça matche (et si on un jour on a une condition négative sur un rôle, et ben on changera la façon de matcher, avec un lack_roles
); ça évitera une explosion du cache comme dans le cas d'un cache par utilisateur.
Mis à jour par Frédéric Péters il y a plus de 5 ans
Combo en passant sur les entrées de menu alimenterait une liste de rôles ("ah il y a un truc qui peut varier en fonction de ce rôle") mais produirait quand même un résultat, qui pour certains utilisateurs ne serait pas bon. Je comprends donc que ce serait donc en amont, à l'appel que l'application devrait dire "je te demande le squelette de telle page, pour quelqu'un qui a ces rôles: (a, b, c)". Etc. Mais ça passe à côté d'une page marquée "juste privée", sans préciser de rôle (= "utilisateurs identifiés"), cas à prendre en compte en plus. Etc. Ça me semble dès le début devenir un truc monstrueux.
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Fichier 0001-general-refine-navigation-menu-page-visibility-28963.patch 0001-general-refine-navigation-menu-page-visibility-28963.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
monstrueux
vs un patch simple. (et ça n'empêche pas à un moment de faire sophistiqué en passant dans hobo etc.) (mais là, perso, overkill).
Mis à jour par Benjamin Dauvergne il y a plus de 5 ans
- Statut changé de Solution proposée à Solution validée
Pas de soucis, asynchrone c'est bien aussi (on pourra toujours travailler sur la possibilité de mettre en cache les rendus asynchrones au moins au niveau navigateur, si on détecte que c'est possible).
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Statut changé de Solution validée à En cours
Au final j'aimerais quand même affiner les choses, qu'on ne bascule pas en asynchrone de manière systématique, que ça se passe uniquement en mode skeleton s'il y a des pages à visibilité restreinte. (pour ne pas basculer une liste de liens dans le pied de page en asynchrone)
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Fichier 0001-general-refine-navigation-menu-page-visibility-28963.patch 0001-general-refine-navigation-menu-page-visibility-28963.patch ajouté
- Statut changé de En cours à Solution proposée
Voilà, plutôt donc que créer un .render() dédié, qui lève l'exception NothingInCache, celle-ci est levée au moment du calcul du menu, ce qui permet d'obtenir le menu en dur dans le squelette s'il n'y a pas de pages privées, en asynchrone sinon.
Mis à jour par Thomas Noël il y a plus de 5 ans
Avec cette détection intelligente, je serais pour ne plus avoir la gestion du "ignore_visibility", parce que ça va juste faire de la confusion. Charge à l'admin fonctionnel de ne pas faire n'importe quoi dans le menu général (ne pas avoir de page privée qui ne soit pas exclue de la navigation). Et encore, s'il fait n'importe quoi, ça marchera quand même, ça sera juste lent et pas joli.
Mis à jour par Frédéric Péters il y a plus de 5 ans
Charge à l'admin fonctionnel de ne pas faire n'importe quoi
Ça va au-delà; j'ai à Quimper un menu additionnel qui contient "mon profil / mes demandes / mes notifications", et je veux ce menu tout le temps, directement (parce que ça se trouve être la navigation de la PWA), mais ces entrées, elles envoient vers des pages qui demandent de l'authent.
Mis à jour par Thomas Noël il y a plus de 5 ans
- Statut changé de Solution proposée à Solution validée
elles envoient vers des pages qui demandent de l'authent.
Elles ne devraient pas, hein (présenter plutôt des cellules qui elles, ont une certaine visibilité).
Bref.
Ack.
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Statut changé de Solution validée à Résolu (à déployer)
Merci.
Elles ne devraient pas, hein (présenter plutôt des cellules qui elles, ont une certaine visibilité).
Noté par jabber mais archivé ici pour mémoire : la navigation du site ne passe pas par des cellules, du coup on n'y bénéficie pas du fallback asynchrone.
commit f3f7202c216b0eb4ddcf573252e642d3fd23df62 Author: Frédéric Péters <fpeters@entrouvert.com> Date: Thu Dec 13 11:16:31 2018 +0100 general: refine navigation/menu page visibility (#28963)
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Statut changé de Résolu (à déployer) à Solution déployée
Mis à jour par Frédéric Péters il y a plus de 3 ans
- Lié à Development #46930: Pouvoir masquer une page dans le menu si elle n'est pas en visiblité publique ajouté
general: refine navigation/menu page visibility (#28963)