Bonjour,
@Alexandre @Luiggi, cette démarche ne fonctionnera pas, "interdire" une capacité produit automatiquement une interdiction de cette capacité QUELQUE SOIT LE CONTEXTE, il ne sera donc plus possible d'autoriser cette capacité à un utilisateur ayant un rôle où cette interdiction est cochée. (cf Comment sont calculées les permissions - prévoir de l'aspirine).
Peut-être en essayant "empêcher" mais j'en doute, car la gestion des fichiers personnels ne s'effectue que dans un contexte particulier, le contexte système, même si l'appel se fait à partir d'un cours ou d'une activité. Cela est d'ailleurs tout à fait logique car les fichiers personnels sont personnels quel que soit l'environnement. Du coup, seuls les rôles attribués au niveau système et leur capacités liées sont étudiés.
Ainsi, seule la procédure indiquée par Mary peut faire l'affaire, même si elle sous entend que les utilisateurs privés de fichiers, censés êtres des étudiants dans certains cours, ne pourront jamais être des tuteurs ou des enseignants performants dans d'autres espaces de cours (associations, bureau des élèves, cours de tutorats ...) puisque dans l'impossibilité de gérer des fichiers.
Une autre solution à creuser, une instance personnelle du File system repository, qui devrait permettre de gérer positivement (j'autorise certaines personnes) plutôt que négativement (j'interdis à tous et je vois après) les possibilités de stocker des fichiers sur le serveur.
Seconde alternative, la mise en place d'un système tiers (genre owncloud) chargé uniquement de la gestion de fichiers (qui peut alors être réglée via LDAP en fonction de groupes, genre "enseignants") et lié (le système) via les dépôts (ici de type webdav). Ça fonctionne parfaitement et cela permet aussi de mieux gérer le versionning, les mises à jour et les soucis de suppression de ressources.
Jérôme.