[SPIP Zone] Plugin Accès Restreint : Comment optimiser l'interface privée ?

Archives Zone
1

Dans un message précédent, j'évoquais la problématique de l'héritage des droits. D'une part, une sous-rubrique ne doit hériter des droits de la rubrique parente qu'à condition qu'elle ne soit pas restreinte par une autre zone. D'autre part, lorsque l'on calcule les rubriques accessibles pour un auteur, il faut vérifier que l'auteur peut effectivement y accéder (il faut avoir également accès aux rubriques parentes). Ces deux règles reposent sur le principe que pour accéder au deuxième étage d'un immeuble, il faut déjà avoir accès au premier étage. De plus, s'il y a un verrou sur la porte du quatrième étage et pas sur celle du troisième, la clé du second étage donne aussi accès au troisième mais pas au quatrième.

Je m'appetais justement ce soir à coder cela ce soir. Or, il faut systématiquement distinguer espace public et espace privé. Mais cela pose quelques soucis d'affichage dans sur la page de gestion des zones. En effet, actuellement, afin de mieux s'y retrouver, les rubriques accessibles sont affichées sur fond de couleur. Mais, dans le cas d'une zone portant à la fois sur l'espace public et sur l'espace privé, une sous-rubrique pourra être accessible sur l'espace public mais pas sur l'espace privé en raison d'une autre zone ne portant que sur l'espace privé. D'où un souci d'affichage. Par ailleurs il serait souhaitable de griser les zones qui ne sont pas accessibles en raison des autres zones actuellement en cours. Ca permet de mieux s'y retrouver entre ses différentes zones. Encore une fois, entre espace public et espace privé ce ne sont pas les mêmes sous-rubriques qui sont concernées. Je dois avouer qu'il faut parfois faire jongler sa mémoire entre les zones que public, que privées et qui filtrent les deux.

SOLUTION 1

J'avais testé une possibilité, décrite ici http://joseph.larmarange.net/Plugin-Acces-Restreint-Modifie.html, qui consistait à déclarer séparément, pour chaque zone, les rubriques filtrées dans l'espace public et celles filtrées dans l'espace privée (voir la capture d'écran sur la page pré-mentionnée). Pour mon usage personnel, cela me paraissait assez simple, privé et public étant clairement séparé. De plus, lorsque pour un même type d'utilisateurs les droits diffèrent entre espace privé et espace public, cela permet de ne définir qu'une seule zone à associer à chaque utilisateur du groupe alors qu'actuellement, il faut définir deux zones et associer à chaque auteur du groupe les deux zones. L'avantage, au-delà de l'économie d'un clic, est de simplifier la gestionde l'attribution des zones pour des administrateurs restreints. Avec cette solution, le problème d'affichage serait résolu.
J'avais commité cette proposition il y a deux semaines mais Cédric m'avait alors demandé de revenir en arrière (http://zone.spip.org/trac/spip-zone/changeset/11373). En effet, il m'avait précisé que le concept de zone correspondait à un ensemble de rubriques. (cédric, n'hésite pas à me dire si je me trompe). Le fait de définir des restrictions différenciées pour un auteur entre public et privé nécessite donc bien, selon ce principe, deux zones. Il ne faudrait pas confondre la notion de zone et celle de profil d'auteurs (pour un essai de début de définition de ce que pourrait être des profils voir ma contribution sur http://www.spip-contrib.net/Gestion-Auteurs.

SOLUTION 2

On pose le fait qu'une zone est soit publique soit privée. Séparation totale entre ces deux espaces. Le problème d'affichage est résolu (puisque l'édition d'une zone ne porte plus que sur un seul des deux espaces). Le concept de zone en tant qu'ensemble de rubriques est préservé. Cependant, pour faciliter la gestion pour les admins du site et s'y retrouver entre zones publiques et zones privées, il faudrait peut-être, sur la page exec/acces_restreint.php afficher séparément les zones publiques et les zones privées et dans le formulaire d'attribution de zone sur la page auteur faire suivre le nom de chaque zone de (publique) ou (privée) pour s'y retrouver plus facilement.
Inconvénient : si on gère un simple espace membre dont les zones sont identiques sur l'espace privé et l'espace public, il faut créer deux zones et associer deux zones à chaque auteur concerné. Encore une fois, la mise en place de profils d'utilisateurs permettrait d'éviter cela mais il s'agit d'un autre chantier et d'un autre débat.

SOLUTION 3

Comme aujourd'hui : une zone est soit publique, soit privée, soit les deux (avec les mêmes rubriques concernées). Utiliser des codes couleurs avec une légende affichée dans la colonne de droite. Outre les rubriques accessibles à la fois dans le public et le privé sur fond blanc, il faudrait a priori pas mal de couleurs (8 je crois) pour couvrir tous les cas de figures :

   * filtrée par cette zone en public
   * filtrée par cette zone en privé
   * filtrée par cette zone en public et en privé
   * filtrée par cette zone en public mais filtrée par une autre zone
     en privé
   * filtrée par cette zone en privé mais filtrée par une autre zone en
     public
   * non filtrée par cette zone mais filtrée par une autre en public
   * non filtrée par cette zone mais filtrée par une autre en privé
   * non filtrée par cette zone mais filtrée par une autre en public et
     en privé

Ca risque de faire confus et d'être difficile de tout saisir au premier coup d'oeil.

SOLUTION 4

Pas de codes couleur mais un complément d'informations à coté du nom de chaque zone sous forme de texte.

SOLUTION 5

Un mixte entre codes couleurs et compléments textuels.

Peut-être existe-t-il d'autres solutions non évoquées ici. Quelle serait, selon vous, la solution la plus simple du point de vue utilisateur de SPIP ? Personnellement je pencherai pour la première mais je ne suis peut être pas objectif.

Joseph LARMARANGE

2

Joseph LARMARANGE wrote:

Dans un message précédent, j'évoquais la problématique de l'héritage des droits. D'une part, une sous-rubrique ne doit hériter des droits de la rubrique parente qu'à condition qu'elle ne soit pas restreinte par une autre zone.

Bonsoir,

Si on veut garder la plus grande souplesse, ne serait-il pas peut-être plus facile de laisser tomber l'idée de l'héritage des droits ? Et que les rubriques qui appartiennent à une zone doivent être choisies explicitement. C'est très simple pour l'utilisateur de cocher/décocher les cases concernées. Et du coup (il me semble) cela peut simplifier bcp. d'autres choses.

Paolo

3

D'une part, une sous-rubrique ne doit hériter des droits de la
rubrique parente qu'à condition qu'elle ne soit pas restreinte par une
autre zone.

Bon, en fait j'ai du mal avec ça. J'imagine très bien un site où le
secteur 10 est interdit car "en travaux", mais subitement la
présidente de la république décide qu'il faut publier sa sous-rubrique
34. Avec l'héritage, c'est impossible.

L'analogie des immeubles ne me parle pas, car sur un site on peut
entrer par n'importe quelle URL, pas seulement par la page d'accueil.
C'est à l'utilisateur d'assurer la cohérence de son truc, non ?

Encore une fois, entre espace public et espace privé
ce ne sont pas les mêmes sous-rubriques qui sont concernées. Je dois
avouer qu'il faut parfois faire jongler sa mémoire entre les zones que
public, que privées et qui filtrent les deux.

Surtout, est-ce que ça sert ? A mon sens le filtrage pourrait être
globalement soit public soit public+privé **pour toutes les zones**.
Du coup on n'aurait plus à se poser cette question.

Alors on va peut-être perdre 10% de fonctionnalité, mais ça
simplifiera grandement le code et l'interface.

Cela dit il faut voir, il y a peut-être déjà de vrais usages de ce sac
d'embrouille.

-- Fil

4

Le 04/05/07, Fil <fil@rezo.net> a écrit :

D’une part, une sous-rubrique ne doit hériter des droits de la
rubrique parente qu’à condition qu’elle ne soit pas restreinte par une
autre zone.

Bon, en fait j’ai du mal avec ça. J’imagine très bien un site où le
secteur 10 est interdit car « en travaux », mais subitement la
présidente de la république décide qu’il faut publier sa sous-rubrique
34. Avec l’héritage, c’est impossible.

Je pense que la perte d’héritage peut être dangeureuse en cas d’ajouts de sous-rubriques dans une zone privée : il faut penser à aller la cocher …

J’ai des mauvais souvenir d’arborescences de pages sur un serveur IIS ou on avait cassé l’héritage des droits, au bout de 2 ans c’était devenu un casse tête inextricable, plus personne n’était capable de dire qu’est qui était géré par qui , il fallait prendre les répertoires 1 par 1.

Pour illustrer un autre pb potentiel dans les derniers sites que j’ai mis en place avec des paramétrages d’accès restreint il y a en général un admin "technique " qui gère le paramétrage (la gestion des zones privées entre autres) et des admins éditoriaux qui ne font que du rédactionnel.

Si la notion d’arborescence n’a plus de sens dans ce cas il faut casser cette notion dans spip et gérer des rubriques liées les une aux autres mais pas forcément arborescentes.
La clarté de l’arborescence de SPIP est un des points qui le rende simple à utiliser. C’est certes une des ses limites.

Encore une fois, entre espace public et espace privé
ce ne sont pas les mêmes sous-rubriques qui sont concernées. Je dois
avouer qu’il faut parfois faire jongler sa mémoire entre les zones que
public, que privées et qui filtrent les deux.

Surtout, est-ce que ça sert ? A mon sens le filtrage pourrait être
globalement soit public soit public+privé pour toutes les zones.
Du coup on n’aurait plus à se poser cette question.

Alors on va peut-être perdre 10% de fonctionnalité, mais ça

simplifiera grandement le code et l’interface.

Cela dit il faut voir, il y a peut-être déjà de vrais usages de ce sac
d’embrouille.

Pas d’exemple à fournir, et je pense aussi qu’il faut simplifier ce point.

a+

–
Arnaud

5

> > D'une part, une sous-rubrique ne doit hériter des droits de la
> > rubrique parente qu'à condition qu'elle ne soit pas restreinte par une
> > autre zone.
>
> Bon, en fait j'ai du mal avec ça. J'imagine très bien un site où le
> secteur 10 est interdit car "en travaux", mais subitement la
> présidente de la république décide qu'il faut publier sa sous-rubrique
> 34. Avec l'héritage, c'est impossible.

Je pense que la perte d'héritage peut être dangeureuse en cas d'ajouts de
sous-rubriques dans une zone privée : il faut penser à aller la cocher ...

Pardon je me suis mal exprimé !

Ce qui m'ennuyait c'est le "à condition qu'elle ne soit pas restreinte
par une autre zone.", mais je me demande si je ne l'ai pas comprise à
l'envers, cette phrase... ou en tout cas l'image des clés de
l'immeuble. Ce n'est pas l'application de la traversée hiérarchique
des rubriques qui pose problème (là dessus on est tous d'accord) ;
c'est les cas d'intersection :

Si j'ai un accès interdit à A, mais accès à B, que se passe-t-il dans
les rubriques qui appartiennent aux deux zones et/ou à leurs
sous-rubriques ?

bref, dodo ; ignorez mon commentaire sur l'héritage :slight_smile:

-- Fil

6

Le 04/05/07, Fil <fil@rezo.net> a écrit :

Si j’ai un accès interdit à A, mais accès à B, que se passe-t-il dans
les rubriques qui appartiennent aux deux zones et/ou à leurs
sous-rubriques ?

bref, dodo ; ignorez mon commentaire sur l’héritage :slight_smile:

– Fil

En matière de sécurité la règle est en général de prendre la restriction la plus forte.
(si on a une approche limite de risque).

Sur ce dodo aussi à suivre. Trop tard pour réfléchir clairement.
a+

Arnaud

7

Fil wrote:

Si j'ai un accès interdit à A, mais accès à B, que se passe-t-il dans
les rubriques qui appartiennent aux deux zones et/ou à leurs
sous-rubriques ?

Pour moi, ce serait non pas "fermer des portes", mais plutôt "donner des accès". Si tu as un accès explicite à B, alors tu peux y aller, même si la rubrique en question appartient aussi à une autre zone à laquelle tu n'appartient pas.

Paolo

8

Paolo a écrit :

Fil wrote:
  

Si j'ai un accès interdit à A, mais accès à B, que se passe-t-il dans
les rubriques qui appartiennent aux deux zones et/ou à leurs
sous-rubriques ?
    
Pour moi, ce serait non pas "fermer des portes", mais plutôt "donner des accès". Si tu as un accès explicite à B, alors tu peux y aller, même si la rubrique en question appartient aussi à une autre zone à laquelle tu n'appartient pas.

Paolo
  

C'est pas tres coherent, car la dite rubrique B a laquelle tu as acces, mais dans la branche A qui t'es interdite, n'aparaitra du coup pas dans la navigation arborescente.
De meme, dans ces pages la, le chemin serait tout cassé.
A partir du moment ou on est dans une logique arborescente il faut y rester, amha.
Cedric

9

Bonjour,

Le 4 mai 07 à 08:51, cedric.morin@yterium.com a écrit :

C'est pas tres coherent, car la dite rubrique B a laquelle tu as acces,
mais dans la branche A qui t'es interdite, n'aparaitra du coup pas dans
la navigation arborescente.
De meme, dans ces pages la, le chemin serait tout cassé.
A partir du moment ou on est dans une logique arborescente il faut y
rester, amha.

C'est ce problème de granularité qui se pose.
Si j'ai dans une rubrique certains articles que je souhaite laisser en accès libre : comment je fais avec ce plugin?
Si je veux que les articles de plus d'un an soient tous en accès libre quels que soient la rubrique : comment je fais avec ce plugin?
L'unité que tu as choisi c'est la rubrique et ses enfants.

Il me semblerait plus logique que ce soit pour l'élément "article" avec un groupe de mots clefs qui gèrent les droits pour répondre aux besoins exprimés par Paolo.

Le plugin acces restreint est actuellement une amélioration de la "rubrique cachée" (c'est ce qui logiquement t'a fait mettre en masqué dans les boucles les rubriques restreintes) ce qui correspond souvent à un besoin d'un espace privé en zone publique.
La logique élémentaire (article) de restriction est plus dans une logique marchande (comme pour moi) ou factuelle (Paolo).

C'est ce qui (si j'ai bien compris) différencie ces approches.

--
Philippe

10

Il me semblerait plus logique que ce soit pour l'élément "article"
avec un groupe de mots clefs qui gèrent les droits pour répondre aux
besoins exprimés par Paolo.

Sur mondediplo.com c'est un mot-clé par article qui définit s'il est
payant ou gratuit. Mais je n'utilise pas accès_restreint, je masque le
#TEXTE au niveau du squelette.

-- Fil

11

Le 4 mai 07 à 09:47, Fil a écrit :

Il me semblerait plus logique que ce soit pour l'élément "article"
avec un groupe de mots clefs qui gèrent les droits pour répondre aux
besoins exprimés par Paolo.

Sur mondediplo.com c'est un mot-clé par article qui définit s'il est
payant ou gratuit. Mais je n'utilise pas accès_restreint, je masque le
#TEXTE au niveau du squelette.

je fais pareil sur allergique.org
un mot clef + un critère de date.

--
Philippe

12

Cédric wrote:

C'est pas tres coherent, car la dite rubrique B a laquelle tu as acces, mais dans la branche A qui t'es interdite, n'aparaitra du coup pas dans la navigation arborescente.
De meme, dans ces pages la, le chemin serait tout cassé.
A partir du moment ou on est dans une logique arborescente il faut y rester, amha.

C'est vrai. Je n'avais pas pensé aux menus, et que des chemins peuvent être "cassés".

Paolo

13

Le 04/05/07, Philippe Auriol <philippe.auriol@gmail.com> a écrit :

Bonjour,

Le plugin acces restreint est actuellement une amélioration de la
« rubrique cachée » (c’est ce qui logiquement t’a fait mettre en masqué
dans les boucles les rubriques restreintes) ce qui correspond souvent
à un besoin d’un espace privé en zone publique.
La logique élémentaire (article) de restriction est plus dans une
logique marchande (comme pour moi) ou factuelle (Paolo).

C’est ce qui (si j’ai bien compris) différencie ces approches.

Je pense aussi que le débat vient bien de ces 2 approches.
Ne faudrait-il pas unifer dans une api ce qui peut l’être (la notion de droits) puis après décliner ces 2 approches éventuellement en 2 plugin différents :

  • une ponctuelle qui permet de limiter l’accès à des
  • une basée sur l’arborescence
    Il y a peut etre une piste possible d’unification en reprenant l’approche qu’on trouve dans le mod_access apache ou on peut dire ce qui l’emporte : l’ouverture ou la fermeture avec la possibilité d’avoir une situation de départ tout ouvert ou tout fermé.
    A+
    –
    Arnaud
14

Le plugin Accès Restreint est un plugin de restriction de zones basé sur l'aboresecence des rubriques. En ce sens, il me semble fondamental que l'on maintienne l'héritage des droits aux sous-rubriques non restreintes par une autre zone et que dans le même temps on vérifie l'accès aux rubriques parentes. L'arborescence doit rester cohérente.
De plus, une fois une zone créée, il importe que les sous-rubriques soit également filtrées sans avoir besoin d'aller modifier la définition des zones. Sur un gros site cela devient très vite ingérable. De plus, un admin restreint peut créer une sous-rubrique mais ne peut modifier la définition des zones (il faut être par défaut admin général).

Certes, il pourrait y avoir intéret à faire des restriction d'accès à des articles sur l'espace public. Mais il s'agit à ce moment là d'une autre logique et cela nécessite de passer par un mot clé attribué à chaque article concerné. Je ne pense pas que cela concerne le plugin accès restreint.

Fil se demande quel intéret à avoir un filtrage différent pour l'espace public et pour l'espace privé. Personnellement, cela m'est utile sur différents sites. Dans certains modes de fonctionnement, il peut exister des processus de validation de textes. Notamment, lorsqu'il s'agit par exemple de valider le compte-rendu d'une réunion (d'un CA, d'une commission, d'un comité etc). Il importe alors que seuls les personnes appartenant puissent avoir accès et modifier un compte-rendu en cours de rédaction dans l'espace privé. Une fois le compte rendu validé par les différents membres et publiés en ligne, ce dernier devra être acceesible coté public par tous les membres. D'où la nécessité d'un filtrage de l'espace privé différent de celui de l'espace public. Ca permet par ailleurs d'utiliser séparément le forum public et le forum privé.
Le filtrage de l'espace privé peut également servir à simplifier la navigation pour des rédacteurs. Si certains rédacteurs ne peuvent écrire que dans certaines rubriques (pour différentes raisons, par exemple uniquement à l'intérieur d'un espace membre) le filtrage de l'espace privé permet de ne leur afficher que les rubriques où ils peuvent écrire des articles. Il devient alors plus facile pour ces derniers de s'y retrouver et cela évite aux admins d'avoir à rechercher en permanence les articles mal rangés. Sur des sites de petites structures, notamment associatives, où les personnes sont pas très à l'aise généralement avec l'outil informatique, cela s'avère parfaois fort utile pour leur rendre l'outil plus accessibles.

Les modes d'organisations sont nombreux. Suivant les cas, il peut être nécessaire d'avoir recours à un filtrage différent entre espace public et privé. Il y a donc déjà des vrais usages de ce plugin.

La question est donc, à mon sens, de voir comment on peut maintenir un filtrage différent entre espace privé et espace public, pour les sites qui en ont le besoin, tout en gardant un fonctionnement simple du coté utilisateur.

Parmi les différentes solutions proposées dans mon précédent mail, il me semble qu'il s'agit soit de la solution 2 (séparer les zones publiques d'un côté et les zones privées de l'autre), soit de la solution 1 (séparer, pour une même zone, la définition du filtrage publique et du filtrage privé).
La solution 2 a l'avantage de faire un distingo très clair et de respecter le concept de zone au sens strict. La solution 1 me semble plus économe coté utilisateur (moins de zones à créer pour les différents usages) même si apparait l'idée de zones hybrides.

Dans les deux cas, il est possible d'afficher sur la page affichant l'ensemble des zones un récaptitualitif des rubriques en montrant lesqelles sont filtrées et si oui par quelles zones afin d'avoir une vue d'ensemble du filtrage.

En restant sur le principe d'un filtrage par rubrique et respectant la structure arborescente de SPIP, quelle solution vous semble la plus adéquate entre la 1 et la 2 du point de vus utilisateur.

Joseph

15

valider le compte-rendu d'une réunion (d'un CA, d'une

Merci pour ces exemples précis et détaillé, qu'il faudrait je crois
mettre dans la doc ou un tutoriel. C'est très parlant.

D'accord aussi sur le filtrage au niveau des articles (un "attribut" suffit).

Et pour ce qui est de l'interface, je crois que le 1. est mieux (c'est
ce qui existe actuellement). S'il faut faire deux zones quand on veut
bloquer des articles *partout*, ça ne va pas.

16

La solution 1 ne correspond pas exactement à ce qui se passe actuellement. En effet, actuellement ondéfinit si une zone est soit publique, soit privée, soit les deux. Dans la solution 1, une même zone peut présenter un filtrage différent pour le public et pour le privé.
Voir Plugin Accès Restreint Modifié - Joseph Larmarange pour un exemple et des captures d'écran de l'interface que l'on obtiendrait.

Fil a écrit :

valider le compte-rendu d'une réunion (d'un CA, d'une

Merci pour ces exemples précis et détaillé, qu'il faudrait je crois
mettre dans la doc ou un tutoriel. C'est très parlant.

D'accord aussi sur le filtrage au niveau des articles (un "attribut" suffit).

Et pour ce qui est de l'interface, je crois que le 1. est mieux (c'est
ce qui existe actuellement). S'il faut faire deux zones quand on veut
bloquer des articles *partout*, ça ne va pas.

17

Dans la solution 1, une même zone
peut présenter un filtrage différent pour le public et pour le privé.
Voir Plugin Accès Restreint Modifié - Joseph Larmarange
pour un exemple et des captures d'écran de l'interface que l'on obtiendrait.

Ah ! Ca je ne le comprends pas, par contre.

Pour moi une "Zone" c'est un ensemble donné de rubriques (et leurs
sous-rubriques). Et pas des ensembles dont la définition fluctue.
Sinon c'est autre chose, du genre un "profil d'utilisateur" (ce qui
avait poussé à faire un accès restreint par groupes).

Justement la direction qu'on veut donner à ce plugin, c'est qu'une
Zone == un ensemble donné de rubriques. Et qu'ensuite les relations
visiteur <-> zones autorisées soient fixées relativement librement (il
y a même un pipeline pour établir les zones autorisées, où tu peux
décider de filtrer sur l'IP ou autre).

-- Fil

18

Fil a écrit :

Dans la solution 1, une même zone
peut présenter un filtrage différent pour le public et pour le privé.
Voir Plugin Accès Restreint Modifié - Joseph Larmarange
pour un exemple et des captures d'écran de l'interface que l'on obtiendrait.

Ah ! Ca je ne le comprends pas, par contre.

Pour moi une "Zone" c'est un ensemble donné de rubriques (et leurs
sous-rubriques). Et pas des ensembles dont la définition fluctue.
Sinon c'est autre chose, du genre un "profil d'utilisateur" (ce qui
avait poussé à faire un accès restreint par groupes).

Justement la direction qu'on veut donner à ce plugin, c'est qu'une
Zone == un ensemble donné de rubriques. Et qu'ensuite les relations
visiteur <-> zones autorisées soient fixées relativement librement (il
y a même un pipeline pour établir les zones autorisées, où tu peux
décider de filtrer sur l'IP ou autre).

-- Fil

D'où le premier mail concernant l'optimisation de l'affichage et les 5 solutions possibles proposées.

Si on part du principe qu'une Zone = un ensemble de rubriques, il s'agit alors des rubriques sélectionnées ainsi que de leur sous-rubriques qui appartiennent à la zone. Or, pour ces sous-rubriques non directement cochées l'héritage des droits et donc l'appartenance à la zone dépend des autres zones (grosso modo, une zone est définie par les portes d'entrées jusqu'aux portes de sortie verrouillées). Si, comme c'est le cas actuellement, une zone peut porter à la fois sur l'espace public et l'espace privé, si les rubriques cochées sont bien les mêmes, les sous-rubriques qui appartiennent à la zone ne sont pas forcément les mêmes que l'on soit sur l'espace public ou l'espace privé (à cause de la définition possible d'une autre zone ne portant que sur l'espace privé par exemple). La zone en tant qu'ensemble de rubriques se retrouve alors hybride car il ne s'agit pas toujours du même ensemble de rubriques coté publique et coté privé. (NB : ce qui est subtil c'est que la définition d'une zone dépend entre autres des autres zones).
Il faut donc une séparation claire entre espace public et espace privé. Soit en passant par la solution 2 (une zone est soit un ensemble de rubriques de l'espace privé soit un ensemble de rubriques sur l'espace public). La notion de zone en tant qu'ensemble de rubriques est donc parfaitement respectée. Seul inconvénient, ca nécessite de multiplier le nombre de zones dans certains cas et, en l'absence de profils d'auteurs, il peut être fastidieux d'avoir à associer à chaque auteur trois zones quand il pourrait s'agit que d'un seul profil, sans parler de la maintenace qui peut être lourde en cas de modification de l'organisation du site.
La solution 1 permet de réduire le nombre de zones nécessaires. Elle offre également une distinction très claire entre espace privé et espace public, distinction qui aparrait au sein de la zone elle-même. Cependant, tu as raison, le concept de zone ne coorespondrait alors plus à un ensemble de rurbique smais plus à une sorte d'hybride entre un profil et une zone.

--
*Joseph LARMARANGE*

19

Mais pourquoi la situation actuelle ne conviendrait pas ? ou une manière de présenter la discussion sous un autre angle.

Actuellement, une fois une rubrique cochée dans une zone, toutes ses sous-rubriques sans execption appartiennent à la zone, indépendemment des autres zones.La définition est simple et calire mais elle pose souci. En effet, si on a une rubrique espace membre avec une sous rurbrique professeurs, on aimerait que les élèves aients accès à espace membre mais pas à professeur.

On pourrait reformuler le problème de la manière suivante : si on prend l'ensemble des rubriques sous la formes d'un arbre, on veut pouvoir définir l'entrée d'une zone (en l'occurence ici espace membre) mais aussi une fin (la zone s'arrête à professeur). Pour le moment, on peut définir l'entrée mais pas la fin.

Comment définir la fin d'une zone ? C'est là que ça se complique.

Cas 1 : La fin d'une zone correspond au début d'une autre zone. C'est assez intuitif. Sachant qu'une autre zone est définie comem débutant à professeurs, on sait que espace membre s'arrete à ce moment là. C'est comme ça que fonctionnait entre autres la version modifié du plugin que j'avais proposé en mars. Mais, cela signifie qu'une zone est définie à la fois par ses portes d'entrées et par celles des autres zones. La définition d'une zone dépend donc à la fois de sa propre définition et de celle des autres. Dans ce cas là, il importe de séparer clairement public et privé (cf. mes précédents messages).
Cette position n'est pas forcément aberrante. On peut prendre l'allégorer des serrures. Pour définir l'entrée d'une zone il suffit de mettre une serrure sur la rubrique en question, serrure qui accepte la clé de la zone. Naturellement, si uen fois entrée dans la zone on tombe sur une porte portant une autre serrure posée par une autre zone, on ne peut plus avancer

Cas 2 : On décide de définir, indépendemment des autres zones, les portes d'entrées et de sortie de la zone en cours, à l'administrateur général d'assurer la cohérence entre les différentes zones. Deux possibilités : A) on coche en dur les rubriques appartenant à la zone. C'est très contraignant sur un gros site. Si on créé des sous rubriques il faut aller les cocher à chaque fois dans la définition de la zone. Bref un tas de problème de maintenance. B) il faut définir les rubriques d'entrée et les rubriques de sortie de la zone. Autrement dit, à côté de chaque rubrique cochée dans l'interface de gestion, il faut une liste de choix entre 'rubrique d'entrée' et 'rubrique de sortie'. La définition de la zone ne dépend plus alors que d'elle même. Elle ne tient pas compte des autres zones. Par contre, le webmaster se devra d'assurer la cohérence entre les différentes zones.

--
*Joseph LARMARANGE*

20

Le 04/05/07, Fil <fil@rezo.net> a écrit :

Dans la solution 1, une même zone
peut présenter un filtrage différent pour le public et pour le privé.
Voir http://joseph.larmarange.net/Plugin-Acces-Restreint-Modifie.html
pour un exemple et des captures d’écran de l’interface que l’on obtiendrait.

Ah ! Ca je ne le comprends pas, par contre.

Pour moi une « Zone » c’est un ensemble donné de rubriques (et leurs
sous-rubriques). Et pas des ensembles dont la définition fluctue.
Sinon c’est autre chose, du genre un « profil d’utilisateur » (ce qui
avait poussé à faire un accès restreint par groupes).

Idem il me semble qu’une zone doit rester une branche du site

Justement la direction qu’on veut donner à ce plugin, c’est qu’une
Zone == un ensemble donné de rubriques. Et qu’ensuite les relations
visiteur ↔ zones autorisées soient fixées relativement librement (il
y a même un pipeline pour établir les zones autorisées, où tu peux
décider de filtrer sur l’IP ou autre).

Dans ce cas on est assez proche de ce qui est fait dans accès ar groupe avec d’un côté les zones et d de l’autre des groupes/paquets d’utilisateurs que l’on peut rassembler en profils

Le plus complexe dans les sytèmes de gestion des habilitations est d’avoir des interfaces claires.

L’idéal est de pouvoir voir quel profil est attaché à une zone et à l’inverse quelles zones sont affectées à un profil et dans le cas qui nous intéresse être capable de faire une synthèse de ces zones pour un user donné en faisant une intersection des droits sur chacune des zone qui donne pour un profil donné la liste des rubriques ouvertes en public / privé ou les 2.

On peut bien sur remplacer user par profil:-) le profil étant un une option pour la gestion de gros site mais qui peut se greffer sur le pipeline d’habilitation via un plugin complémentaire par exemple pour reproduire acces resteint par groupe qui permet la déclaration d’autre chose que des utilisateurs dans une zone.

A+

Arnaud