Sem@tic

Voir les impacts

Globalement la différentiation existe presque actuellement car la méthode Page.getRootPage prend un paramètre doFilter qui permet de récupérer l’arbre des pages en filtrant selon les droits d’accès ou non. Presque tous les appels effectués depuis le backoffice désactivent le filtrage, et tous les appels effectués depuis le front l’activent. Quelque part, ce booléen encode le même concept que le dédoublement page.front.read/page.back.read, ou, au moins, il permettra une migration plus smooth :

• Partout où l’appel est effectué avec doFilter = false, utiliser l’action page.back.read ;
• Partout où l’appel est effectué avec doFilter = true, utiliser l’action page.front.read ;
  • Selon que le lieu d’appel correspond au backoffice, adapter au cas par cas le code :
    • Dans l’init de library (engine/app/bootstrap/Bootstrap.java) ;
    • …
• Proposer un script de migration :
  • Pour tous les profils contenant l’action page.read, la remplacer par page.front.read ;
  • Ajouter l’action page.back.read pour le profil Administrateur ;

Ah, je pense que je viens de comprendre ce ticket.

Le besoin est le suivant : rendre des pages administrables (dans le backoffice) par certaines personnes seulement.

Actuellement, si l’on restreint la visibilité d’une page à un utilisateur ou un groupe, en utilisant la permission page.read, celle-ci devient invisible pour tous les autres, en back et en front.

Il faudrait donc un page.backoffice.read, pour restreindre la visibilité d’une page dans le backoffice seulement (et un page.frontoffice.read si l’on souhaite restreindre la visibilité d’une page en front).

cb046e37