Je construis un site simple Drupal 7 qui a des pages publiques et des pages réservées aux membres. Il n'y a qu'un seul type de membre. Pour le moment, le contrôle d'accès n'a pas besoin d'être plus fin que cela. Il semble mes choix sont les modules accès au conten , Nodeaccess , accès simple , byrole de confidentialité des nœuds , taxonomie Contrôle d'accès et Taxonomy Access Control Lite . Pour obtenir ce dont j'ai besoin, je pouvais contrôler l'accès soit par rôle, soit en utilisant un terme de taxonomie comme "réservé aux membres". Les deux fonctionneraient.
Tous ces modules sont encore en cours de développement pour D7, et sont à différents stades d'achèvement et de bogue. Pour certains, le développement semble erratique ou au point mort. De plus, leurs UX sont de complexité variable pour l'éditeur de contenu non sophistiqué.
(Une autre alternative à tous ces modules consiste à créer un type de contenu distinct pour les pages réservées aux membres, et à utiliser simplement les autorisations de type de contenu intégrées. Cela semble rigide et dupliqué, mais c'est une solution.)
Ma question est d'ordre pratique, compte tenu de la réalité actuelle: laquelle choisiriez-vous d'utiliser maintenant ou dans les prochains mois, pour ce cas d'utilisation, et laquelle semble avoir le plus bel avenir?
SUIVI (7 mois plus tard): Après avoir essayé Content Access (CA) et Taxonomy Access Control (TAC), je me suis installé sur TAC. L'accès au contenu peut faire un contrôle d'accès par nœud, mais l'UX n'est pas simple, et je ne voudrais pas y soumettre mes éditeurs. Je trouve que l'utilisation d'un terme de taxonomie pour désigner l'accès peut être essentiellement un mécanisme d'abstraction: un seul terme peut représenter un ensemble compliqué de choix d'accès. Pour un type de contenu (événements de calendrier), je fais varier l'accès en fonction de la taxonomie. Pour un autre (pages réservées aux membres), j'utilise simplement un vocabulaire de taxonomie à un terme qui est un champ obligatoire (donc sa valeur ne peut pas changer). Donc pour moi, la fonctionnalité de TAC est un surensemble de CA. J'avais également besoin de Autorisations de champ pour exposer sélectivement les champs dans les événements de calendrier.
Évidemment, il y a beaucoup de facteurs que vous devez considérer avant de décider si un module a un avenir "brillant" ou non. Un très bon article de blog qui décrit tous les facteurs à considérer peut être trouvé ici (il est basé sur l'ancien thème de drupal.org mais vous pouvez toujours comprendre).
La décision finale que vous prendrez est une sorte de "sentiment" que vous obtiendrez après avoir passé beaucoup d'heures à tester des modules et à vous cogner la tête contre le mur, seulement pour réaliser que le module que vous avez choisi n'est pas le bon. Cependant, je vais vous donner les résultats d'un petit script que j'ai et que je lance dans de tels cas. Il vous donne le nombre d'utilisation des modules que vous fournissez en entrée, et les voici:
Notez que ces résultats ne sont que des informations tirées du site Web drupal.org et que vous ne devez pas les utiliser pour comparer les modules. Ce ne sont que des indications qui vous indiquent ce que les autres utilisateurs pensent des modules que vous examinez.
Donc, pour répondre à votre question, j'opterais pour le module d'accès au contenu car il prend en charge l'accès par rôle que vous avez mentionné, il y a des tonnes de sites qui l'utilisent (ce qui signifie qu'il est très peu probable qu'il soit interrompu), son auteur est quelqu'un qui a fait un travail remarquable pour drupal et la version D7 a été mise à jour-relativement- récemment).
P.S: si vous voulez le script, laissez-moi le savoir. C'est très pratique dans de nombreux cas.
Vous pourriez être intéressé par le module Contenu Premium, http://drupal.org/project/premium_content , qui fonctionne d'une manière similaire à ce que vous cherchez apparemment.
Fournir une autorisation d'accès à une page de base semble difficile dans Drupal. Il est cependant possible d'accorder des autorisations pour les pages créées de la vue. Ainsi, il est simple d'ajouter simplement une vue au lieu d'une page de base !! cache même l'élément de menu !!