permission Drupal, un cas d'utilisateur

Question

L'objectif du site est de maintenir une liste product.

• Chaque product COMPOSES d'un titre, Description et quantité (champ CCK). Chaque product appartient à un shop. Chaque shop a manager. Tous les products sont visibles par tous.
• Un manager peut seulement ajouter/éditer products de son propre shop.
• Un site admin peut créer un nouveau shops et un nouveau managers.

Comment puis-je définir l'autorisation pour le scénario ci-dessus?

Je pense à utiliser Taxonomy pour les noms de magasins, Taxonomy Access Control pour le contrôle des autorisations. Je ne sais pas si je suis sur la bonne voie si ...

En outre, est Organic Groups également une option?

Merci!

Answer 1

TAC résout vos problèmes. Je l'utilise dans un scénario très similaire. Voilà comment le configurer:

1. Créer un nouveau type de contenu « produit » avec les champs que vous avez spécifié
2. Créer un terme de taxonomie pour chaque magasin. Activer et exiger la taxonomie sur le « produit » type de contenu
3. Créer un rôle pour chaque magasin
4. Activer TAC pour ce rôle
5. Définissez les autorisations de TAC pour global pour permettre View, mais refuser de mise à jour, Supprimer, Créer et Liste .
6. Définissez les autorisations TAC pour le terme de la boutique pour autoriser Afficher, Mettre à jour, Supprimer, Créer et Lister.
7. Enregistrer et reconstruire les autorisations

Cela devrait le faire, aussi longtemps que vos autorisations pour le type de contenu sont mis en place pour permettre aux utilisateurs anonymes pour afficher les champs « produit ».

Answer 2

Je pense que votre approche avec Taxonomy Access Control peut être un travail, mais attribuer aux utilisateurs une taxonomie pour les autorisations appropriées nécessiterait un peu de code personnalisé. L'utilisation de groupes organiques peut fournir un accès plus robuste dès la sortie de la boîte (chaque boutique est un groupe et les produits sont ensuite publiés dans ce groupe), mais vous devrez en retirer beaucoup de paramètres par défaut afin de masquer le forum/mur de l'information workflow que OG vient avec hors de la boîte (cela peut être fait avec les crochets OG fournit).

L'avantage ici est que pour ajouter des chefs de produit à un magasin, vous en feriez simplement l'administrateur du groupe (un magasin pourrait avoir plusieurs administrateurs de cette façon). Vous devez définir chaque groupe comme public (de sorte que tous les produits sont visibles), mais accorder uniquement la permission d'éditer les noeuds du groupe à l'administrateur de ce groupe. Les administrateurs de groupe seraient également les seuls à avoir la permission de créer des nœuds de produits, qui seraient configurés en tant que nœuds de groupe (ceci est fait à l'écran d'édition de type nœud, ou à l'écran d'administration OG).