Message d'avertissement

The subscription service is currently unavailable. Please try again later.

Habilitations

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

Bonjour,

Pour le développement de notre Intranet, j'ai besoin d'affecter des habilitations de consultation par page et même par documents uploadés.
En effet, nous avons une hiérarchie Directeurs, chefs de service et utilisateurs courants.

Certaines pages ne peuvent-être visualisées que par les directeurs et/ou chefs de services. Certaines autres pages par tous.

De plus des pages visibles par tous peuvent contenir des pièces jointes (fichiers uploadés à partir de filefield de CCK) visibles que par les directeurs par exemple.
Comment est-ce possible avec Drupal ? Existe t'il un ou plusieurs modules pour cette gestion :
1- habilitations par page.
2- habilitation par fichiers uploadés dans ces pages.

Merci de votre aide.

Version de Drupal : 

Il y'a plusieurs façons de faire.

Si tu as quelques droits bien établis, je pense que tu peux utiliser Taxonomy Access Control. En clair, chaque page va se voir attribuer un terme qui te permettra d'attribuer des droits à des rôles.
http://drupal.org/project/taxonomy_access

Cela marchera très bien pour la consultation. Par contre qu'en est il pour pousser les infos? Dans ce cas là il faudra peut-être voir si Organic Groups n'est pas plus adapté.

Il y a souvent plusieurs choix possibles avec Drupal donc effectivement on peut utiliser taxonomy access control (ou TAC Lite) mais on peut aussi opter pour content access qui est très complet.

Pour contrôler au niveau du champ lui-même par contre il faudra regarder du côté de modules comme CCK Field Permissions

En gardant toujours à l'esprit qu'utiliser plusieurs modules de contrôle des accès est un exercice périlleux avec Drupal, car il suffit qu'un module accorde la permission d'accéder (GRANT et non DENY) pour que les permissions définies par un autre module soient supplantées (la logique de contrôle des accès est basée sur un OU logique et non un ET).

Heureusement tout n'est pas perdu avec Module Grants qui change le fonctionnement par défaut de Drupal vers un ET logique au lieu du OU, si on veut vraiment avoir plusieurs module de contrôle des accès concurrents.

Attention par contre, ça ne résoud pas tout et il faut procéder par ordre et avec prudence dès qu'on modifie un élément aussi essentiel que le contrôle des accès...

Un petit truc encore, pour les documents, ne pas oublier de configurer drupal pour qu'il gère les téléchargements de fichiers, sinon l'utilisateur ayant le lien vers le fichier pourra le récupérer.

Synthèse je ne sais pas, parcequ'il existe une multitude de modules (et aussi une multitude de besoins) mais c'est une bonne idée que de formaliser à un moment donné sur la doc... j'essaierai de prendre un peu de temps pour faire ça.

Effectivement la méthode de téléchargement privé est conseillée mais attention ça pose ensuite d'autres problèmes (notamment au niveau de l'optimisation des css et js par Drupal, du coup on n'a plus la réduction à 1 fichier pour réduire le nombre de requête HTTP). Une autre solution est de passer par une solution autre que celle proposée par Drupal par défaut (par exemple, WebFM)

Merci mais le module CCK Field Permissions n'existe pas pour la version 6 de Drupal...
Avez-vous une autre idées pour donner des habilitations sur les fields cck ?
Exemple : sur une page, un champ CCK filefield avec 5 fichiers possibles.
Avoir la possibilité de dire que tel fichier est visible pour tel ou tel rôle...
MERCI

tu as dans CCK pour D6 un sous modules qui s'appelle Content Permissions qui permet de fixer les permissions pour les champs selon les roles.peut être que tune l'a pas activé dans /admin/build/modules

Bonsoir à tous,

Je me permet de revenir sur cette discussion car le module Content Access m'interesse.

je souhaiterais qu'à la création d'un contenu je puisse, par un bouton radio ou autre, sélectionner le ou les rôles qui peuvent y avoir accès.
Est ce le bon module ? quelqu'un connait-il le module Node Access je n'arrive pas a voir la différence qu'il y a avec Content Access...
Merci d'avance de vos éclairages...

Cordialement,
Thib'

A ce jour, j'utilise node access qui permet de donner des habilitions précisent par type de conteneur et par node (plus précis que content node et convient mieux à nos attentes).
Cela fonctionne très bien pour le contenu mais il n'y a pas de gestion de droit jusqu'aux fichiers uploadés.... Pour le moment, le contenu est protégé mais pas les fichiers qui lui sont joints.

Bonjour Mimi19,

Pour protéger les contenus, peut-être que http://drupal.org/project/private_upload pourrait faire l'affaire ? Si un utilisateur a accès au node qui référence les fichiers, et que pour l'upload des fichiers on a cliqué privé, il peut y avoir accès. Les autres utilisateurs qui n'ont accès à aucun des nodes référançant ce fichier, n'y auraient pas accès, même en mettant l'url et même si drupal est en mode accès libre pour les téléchargements.

Qu'en penses-tu ?

Peut-être voir aussi ce sujet http://www.onyxbits.de/content/drupal-and-problem-protecting-uploaded-files ou Patric a aussi posté des commentaires sur ce sujet : http://www.drupalcoder.com/story/406-mixing-private-and-public-downloads...

Hum quoi que comme disait Davidm, on dirait que WebFM peut gérer les droits d'accès sur un fichier, avec en prime toutes les fonctions supplémentaires qu'il apporte... on dirait que c'est plus pratique que private_upload, non ?