Re: Discussion avant pull request sur autorisation pour accès à <:bouton_cache_desactiver:>

Hello,

ça ne me parait pas scandaleux de mettre une autorisation spécifique sur le bouton « désactiver temporairement le cache » même si par défaut elle restera identique, je t’invite donc à proposer une PR en effet.

Mais sur le fond, ça me parait par contre bizarre que des admins restreint aient besoin d’accéder au bouton « vider le cache ».
Pour tout dire ce bouton ne devrait jamais servir dans la vie courante du site, c’est vraiment en processus de développement qu’il peut être utile, si on modifie les squelettes par exemple.

Aujourd’hui la simple publication d’un article ou tout autre action éditoriale implique une invalidation de tout le cache, une action de vidage ne devrait donc avoir aucun effet supplémentaire (si ce n’est psychologique pour se rassurer, ou par habitude acquise sur les anciennes versions de SPIP).
Sans remettre en cause ta proposition initiale je ne pourrai que t’inviter à creuser un peu ce problème et éventuellement à nous remonter des scénario précis qui justifieraient vraiment ce vidage de cache qu’on pourrait améliorer.

Bonne journée à toi,

--
Cédric
Le 22 janv. 2019 à 21:40 +0100, 6ril <[email protected]>, a écrit :
> Le 22/01/2019 à 21:20, 6ril a écrit :
> > Bonsoir,
> > Je souhaiterai formuler le vœu de pouvoir si on le souhaite distinguer
> > l'accès à cette fonctionnalité  (le bouton "désactiver temporairement le
> > cache" du formulaire admin_vider_cache) de l'accès à la page intégrale
> > de vidage de cache, ceci grâce à une autorisation explicite, dérogeant
> > au principe actuel que la désactivation soit utilisable par qui accède
> > au formulaire général du cache.
> >
> > Ceci pour différencier les droits d'un admin restreint de ceux d'un
> > webmestre, cette fonctionnalité semblant d'avantage vouée au dev qu'à
> > une administration restreinte du site.
> >
> > Peut-être ce sujet a-t'il déjà été débattu, ce que j'ignore, et c'est la
> > raison pour laquelle, avant de poster un request d'amélioration sur
> > https://core.spip.net/projects/spip/issues, il m'a semblé plus opportun
> > de demander avant ici si l'idée paraissait la peine d'y être posée ?
> >
> > Perso, actuellement, n’ayant trouvé d'autres palliatifs subvenant à mes
> > besoins, je pose un [(#AUTORISER{webmestre}|oui)] en surcharge dans un
> > squelette perso
> > squelettes/prive/squelettes/inclure/admin_vider_cache.html, mais ça me
> > pose le problème de devoir regarder à chaque release de Spip si une
> > modif a été faite sur le squelette de la distrib pour refaire le mien.
> >
> > Bref, s'il y avait en natif un
> > (#AUTORISER{bouton_cache_desactiver}|oui)] pour ce bouton, ou un autre
> > procédé du genre permettant de l'occulter si besoin, je mettrai une fois
> > pour toutes dans mes_options une surchage de cette autorisation pour la
> > limiter aux seuls webmestres.
> >
> > Merci si vous pouviez m'indiquer si je peux lancer une request dans ce
> > sens ou directe abandonner l'idée et continuer de bidouiller dans mon coin.
> >
>
> J'oubliais, indispensable pour une meilleur compréhension, j'ai
> absolument besoin de donner aux admins restreints le droit sur le vidage
> de cache et j'ai donc surchargé ainsi dans mes_options:
> function autoriser_configurer($faire, $type, $id, $qui, $opt)
> {
> //echo 'faire: ' .$faire . ' - type: ' .$type;
> //return false;
> if (isset($type)) {
> if ($type == 'adminvider') {
> return $qui['statut'] == '0minirezo';
> }
> }
> return $qui['webmestre'] == 'oui';
> }
>
> En effet, un admin restreint doit pouvoir, sur mon projet, et d'après
> mon expérience de pas mal d'année à présent, avoir la main sur ses
> publications. Cet aspect peut faire partie de la discussion, bien
> entendu. Ceci dit, après moults recherches j'ai trouvé cette capacité de
> pouvoir le faire (fonction autoriser_configurer), alors je me demandais
> si on ne pouvait pas affiner jusqu'à lui restreindre l'autorisation sur
> la seule désactivation temporaire du cache, ce qui de mon point de vue
> est un privilège bien plus élevé que le reste du formulaire, à réserver
> au dev.
>
> _______________________________________________
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: http://www.spip.net/
> dev: http://trac.rezo.net/trac/spip/
> irc://irc.freenode.net/spip