Soit un site extranet sous Drupal 6 que je souhaite monter pour mettre du contenu à disposition. Ce contenu est à destination de x entreprises et chaque entreprise dispose d’un certain nombre de services distincts.
Le site aura plusieurs types de contenu :
1. Celui visible par tous, même sans authentification
2. Celui visible pour une entreprise donnée et elle seule
3. Celui visible pour un seul service d’une entreprise donnée
Si on disposait ce contenu dans un tableau à 2 dimensions avec en colonnes les services et en ligne les entreprises, je voudrais pouvoir réduire les permissions d’accès à une ligne voire une cellule.
Il sera créé pour chaque entreprise :
- un compte par service, compte qui ne devra avoir accès qu’a ce qui concerne son entreprise, pour son service uniquement ainsi que des documents rendus publics pour l’entreprise uniquement.
- un compte de coordinateur, qui aura, lui, accès à tout ce qui concerne son entreprise, tous services confondus.
Quelle est la solution la plus élégante pour parvenir à cette fin ?
Pour information j’ai cherché du côté des modules suivants :
- content_access : pas assez souple
- taxonomy_access_control : je ne peux pas restreindre l’accès sur la base d’un cumul d’attributs. Je peux restreindre à un service OU à une entreprise. Dans mon tableau à deux dimensions ça représente une zone constituée d’une colonne croisant une ligne mais pas l’unique cellule à l’intersection des deux
- nodeaccess : on ne peut pas faire plus fin qu’avec ce module, dans lequel on précise, nœud par nœud, quels rôles et/ou quels utilisateurs individuels peuvent faire quoi… mais faute d’automatisation ce sera fastidieux en diable. Si je pouvais «scripter» cette option pour appliquer en masse des permissions d’accès sur la base de critères prédéfinis, pourquoi pas.
- rules : ça semble intéressant… mais costaud à mettre en place, en conjonction avec le module tokens
Une solution basée une la taxonomie serait intéressante. Je voudrais pouvoir systématiser la chose pour mettre ça entre les mains d’un non-drupalien sans devoir le former une semaine pour qu’il soit autonome…
Des idées ? J’ai au passage une condition supplémentaire : le site, initialement monté sous Drupal 6, ne devrait s’appuyer que sur des modules pour lesquels une version «D7» existe déjà…
- Vous devez vous identifier ou créer un compte pour écrire des commentaires
Salut AP41,
Pour ma part, je crois qu’il te faudrait regarder du coté d’Organic Group.
Par contre, ayant déjà fait un site relativement proche du tien, je te souhaite beaucoup de courage :o/ …
Denis75
129
Je pense que c’est faisable avec Taxonomy Access Control. Cela ressemble un peu à ce que j’ai fait pour un site.
Je dirais qu’il te faudrait créer 3 vocabulaires : Confidentialité, Entreprises et Services.
— Confidentialité contiendrait Public et Privé, tu mettrais en Public ce qui doit être vu de tous, en Privé le reste qui est pour les entreprises ou services.
— Entreprises contiendrait les noms des entreprises. Tu renseignerais les entreprises ayant accès à la node en la créant. Si ça doit être visible que d’un service particulier de l’entreprise, ne rien mettre (par défaut, la node n’en a pas donc).
— Services contiendrait les noms des services de toutes les entreprises (format nomEntreprise_nomService par exemple). Tu renseignerais de la même façon les services ayant accès à la node à la création. Si ça doit être visible de toute l’entreprise, ne rien mettre (par défaut, la node n’en a pas donc).
Ensuite, dans Taxonomy Access Control, tu mets :
— Unauthenticated User : Pour la taxonomie Public, Allowed, sinon tu laisses Ignore (qui sera Denied en l’occurrence).
— Authentificated User : Public = Allowed.
Et ensuite, un rôle par service, avec :
— taxonomie Entreprises : sonEntreprise = Allowed
— taxonomie Services : sonService = Allowed
Le réglage de base étant en Ignore négatif (donc Denied si on a pas spécifié Allowed), cela donnera les droits suivants :
— Non identifié : Ne voit que les nodes Public.
— Identifié : Voit que les pages Public (mais dans le principe ce rôle n’est pas utilisé, chaque User aura un rôle de service qui hérite de celui-là)
— Identifié à un service : Voit ce qui est tagué à son Entreprise (ce qui est tagué à une autre ou à aucune [=spécial pour un service] reste en Ignore négatif) et voit ce qui est tagué à son Service (ce qui est tagué à un autre reste en Ignore négatif).
Je garantie pas que j’ai tout bon, je dis tout ça de tête, mais ça doit ressembler à ça.
Deeder
1
Merci beaucoup Denis75 et Deeder pour vos suggestions.
@Denis75 : Organic groups a l’air très puissant mais bien costaud à paramétrer. Il se trimballe un paquet de dépendances. Son système de notifications en cas de nouveautés est, cela-dit, fort séduisant.
@Deeder : Effectivement, si on restreint l’accès sur un terme donné de taxonomie, on arrive à nos fins. Techniquement ça marche mais il faut créer jusqu’à a*b entrées ou a est le nombre d’entreprises et b le nombre de services maximum pour une entreprise. Le module «Taxonomy CSV import/export» est en l’occurrence très pratique pour des imports et exports en masse, dans différents formats.
Voici actuellement ce vers quoi je me dirige. Le module «Content access», utilisé seul, permet de déterminer les permissions des rôles existants par rapport à un type de contenu. Couplé au module «ACL», Content access permet d’aller plus loin en permettant de donner des permissions individuelles aux nœuds (nodes). Pour un nœud donné, on peut spécifier les prérogatives des différents rôles et aussi, facultativement mais c’est ce qui m’intéresse, celles de comptes utilisateurs individuels.
Le top pourrait être d’utiliser le module «Rules» (règles personnalisées exécutées dans tel ou tel contexte, dans des conditions définies) afin, quand les attributs de taxonomie d’un nœud sont modifiées, de mettre à jour la liste des utilisateurs associés. Plus ça va plus je me dis que ça va finir les mains dans le PHP ou dans la base de données (cette dernière option étant délicate si on ne veut pas mettre le bazar partout).
À défaut d’automatiser complètement tout (ce qui serait quand même l’idéal), j’ai intérêt à potasser tout ce qui permet de réaliser des opérations en masse (genre : une extraction sur un certain nombre de critères me renvoie x documents ; je veux, sur ces x documents, poser des permissions d’accès ou réinitialiser les permissions).
La gestion du site sera au final remise au mains d’utilisateurs non drupaliens. Je cherche donc à systématiser, formaliser les choses autant que possible afin de rendre la gestion d’un contenu volumineux aussi peu fastidieuse que possible.
AP41
2