Projet

Général

Profil

Development #28963

révision de la prise en compte de la visibilité des pages dans les menus

Ajouté par Frédéric Péters il y a plus de 5 ans. Mis à jour il y a plus de 5 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
13 décembre 2018
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:

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

Lié à Combo - Development #46930: Pouvoir masquer une page dans le menu si elle n'est pas en visiblité publiqueRejeté23 septembre 2020

Actions

Révisions associées

Révision f3f7202c (diff)
Ajouté par Frédéric Péters il y a plus de 5 ans

general: refine navigation/menu page visibility (#28963)

Historique

#1

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.

#2

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.

#3

Mis à jour par Frédéric Péters il y a plus de 5 ans

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).

#4

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).

#5

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)

#6

Mis à jour par Frédéric Péters il y a plus de 5 ans

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.

#7

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.

#8

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.

#9

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.

#10

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)
#11

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
#12

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é

Formats disponibles : Atom PDF