« Dérogation aux permissions » : différence entre les versions

De MoodleDocs
Aller à :navigation, rechercher
Ligne 24 : Ligne 24 :
:Cette valeur est très puissante et ne doit être employée qu'en de rares occasions. Mais parfois vous pourriez vouloir refuser complètement des autorisations à un rôle d'une manière qui ne peut être remplacé à tout contexte inférieur. Avec la valeur "Interdire", vous vous prémunissez d'une dérogation qui serait accordée ailleurs et refuse totalement la permission sur une capacité. Un exemple de situation où vous pourriez avoir besoin de cette dérogation est quand un administrateur veut interdire à une personne de commencer de nouvelles discussions dans un forum sur l'ensemble du système. Dans ce cas, il faudra créer un rôle dédié avec cette capacité réglée sur "Interdire", puis l'affecter à cet utilisateur dans le contexte du système. Quelque soit les autres autorisations données à cet usager, il ne pourra jamais plus obtenir cette permission sur cette capacité.
:Cette valeur est très puissante et ne doit être employée qu'en de rares occasions. Mais parfois vous pourriez vouloir refuser complètement des autorisations à un rôle d'une manière qui ne peut être remplacé à tout contexte inférieur. Avec la valeur "Interdire", vous vous prémunissez d'une dérogation qui serait accordée ailleurs et refuse totalement la permission sur une capacité. Un exemple de situation où vous pourriez avoir besoin de cette dérogation est quand un administrateur veut interdire à une personne de commencer de nouvelles discussions dans un forum sur l'ensemble du système. Dans ce cas, il faudra créer un rôle dédié avec cette capacité réglée sur "Interdire", puis l'affecter à cet utilisateur dans le contexte du système. Quelque soit les autres autorisations données à cet usager, il ne pourra jamais plus obtenir cette permission sur cette capacité.


==Conflict resolution of permissions==
==Résolution de conflit de permissions==
Les autorisations dans un contexte « inférieur » remplaceront généralement celles délivrées dans un contexte « plus élevé » (cela vaut pour les dérogations et les rôles attribués). L'exception est INTERDIRE qui ne peut être remplacé à des niveaux inférieurs.


Permissions at a "lower" context will generally override anything at a "higher" context (this applies to overrides and assigned roles). The exception is PROHIBIT which can not be overridden at lower levels.
Si deux rôles sont attribués à une même personne dans un contexte spécifique, une avec AUTORISER et l'autre avec EMPÊCHER, alors AUTORISER l'emporte.


If two roles are assigned to a person in any context, one with ALLOW and one with PREVENT, then ALLOW will win.
===Exceptions===
 
Notez que le compte ''invité'' sera généralement ''empêché'' de publier du contenu (par exemple, des forums, des entrées de calendrier, blogs), même si cette capacité lui est donnée par dérogation.
===Special exceptions===
 
Note that the guest user account will generally be prevented from posting content (eg forums, calendar entries, blogs) even if it is given the capability to do so.


==Locations for overriding permissions==
==Locations for overriding permissions==

Version du 10 février 2016 à 15:57

Remarque : la traduction de cette page n'est pas terminée. N'hésitez pas à traduire tout ou partie de cette page ou à la compléter. Vous pouvez aussi utiliser la page de discussion pour vos recommandations et suggestions d'améliorations.


Les dérogations sont des permissions spécifiques destinées à substituer des droits (capacités) d'un rôle dans un contexte particulier, vous permettant ainsi d' "ajuster" les autorisations aux besoins.

Les dérogations peuvent être utilisées pour « libérer » des parties d'un cours (activité, bloc,...) en donnant aux utilisateurs des autorisations supplémentaires. Par exemple, une dérogation peut être utilisée pour permettre aux élèves d'évaluer des messages du forum (voir Paramètres du forum pour plus de détails).

Les dérogations peuvent également être utilisées pour empêcher des actions, telles que le démarrage de nouvelles discussions dans un forum archivé.

Permissions

CAPTURE

Il existe 4 valeurs possibles par permission de capacité :

Hériter
C'est le réglage par défaut. Si une capacité est configurée pour hériter, alors les autorisations de l'utilisateur restent les mêmes que dans le contexte supérieur, ou dans un autre rôle qui lui est attribué où la capacité est définie. Par exemple, si un étudiant est autorisé à effectuer une tentative au test au niveau des cours, ce rôle dans un test spécifique héritera de cette permission. Au final, si l'autorisation est jamais définie à tous les niveaux de contexte supérieur, l'utilisateur n'aura pas de permission pour cette capacité.
Autoriser
Cela autorise un utilisateur à employer une fonction dans un contexte donné. Cette autorisation vaut pour le contexte dans lequel le rôle est attribué, ainsi que tous les contextes inférieurs. Par exemple, si un utilisateur se voit attribuer le rôle de l'élève dans un cours, et qu'on autorise, dans un forum spécifique, ce rôle à supprimer des messages, il sera en mesure de modérer des discussions dans ce forum mais pas dans les autres forums de ce cours.
Empêcher
En choisissant cette valeur, vous supprimez la permission sur cette capacité (uniquement pour ce rôle), même si les utilisateurs disposant de ce rôle ont obtenu cette permission dans un contexte plus élevé. Si un autre rôle permet la même capacité, même pour un cadre supérieur ou inférieur, cet empêchement n'aura aucun effet. Reprenons notre exemple d'étudiant dans un cours, autorisé donc, par défaut, à ajouter de nouvelles discussions dans les forums, si un forum contient une dérogation dont la valeur est sur empêcher pour la capacité concernée (soit "Lancer des discussions" ou mod/forum:startdiscussion), il ne pourra pas initier de fil de discussion. Par contre, il pourra répondre si on lui laisse cette permission.
Interdire
Cette valeur est très puissante et ne doit être employée qu'en de rares occasions. Mais parfois vous pourriez vouloir refuser complètement des autorisations à un rôle d'une manière qui ne peut être remplacé à tout contexte inférieur. Avec la valeur "Interdire", vous vous prémunissez d'une dérogation qui serait accordée ailleurs et refuse totalement la permission sur une capacité. Un exemple de situation où vous pourriez avoir besoin de cette dérogation est quand un administrateur veut interdire à une personne de commencer de nouvelles discussions dans un forum sur l'ensemble du système. Dans ce cas, il faudra créer un rôle dédié avec cette capacité réglée sur "Interdire", puis l'affecter à cet utilisateur dans le contexte du système. Quelque soit les autres autorisations données à cet usager, il ne pourra jamais plus obtenir cette permission sur cette capacité.

Résolution de conflit de permissions

Les autorisations dans un contexte « inférieur » remplaceront généralement celles délivrées dans un contexte « plus élevé » (cela vaut pour les dérogations et les rôles attribués). L'exception est INTERDIRE qui ne peut être remplacé à des niveaux inférieurs.

Si deux rôles sont attribués à une même personne dans un contexte spécifique, une avec AUTORISER et l'autre avec EMPÊCHER, alors AUTORISER l'emporte.

Exceptions

Notez que le compte invité sera généralement empêché de publier du contenu (par exemple, des forums, des entrées de calendrier, blogs), même si cette capacité lui est donnée par dérogation.

Locations for overriding permissions

  • Front page context: Administration > Front Page settings > Users > Permissions
  • Course category context (when used):Category > Administration > Permissions
  • Course context: Administration > Course administration > Users > Permissions
  • Module context: (from the chosen module) Administration > Module administration > Permissions
  • Block context: (from the chosen block) Administration > Block administration > Permissions
  • User context: (from the user's profile) Administration > Roles > Permissions

Ability to override permissions

Users who have the capability moodle/role:override allowed or the capability moodle/role:safeoverride allowed) can override permissions for selected roles (as set in Allow role overrides).

The default manager role has the capability moodle/role:override allowed, and can override permissions for all other roles.

The default teacher role has the capability moodle/role:safeoverride allowed, and can override permissions for the roles of non-editing teacher, student and guest.

Enabling non-editing teachers to override safe permissions

  1. Access Administration > Site Administration > Users > Permissions > Define roles.
  2. Edit the non-editing teacher role and change the capability Capabilities/moodle/role:safeoverride to allow.
  3. Click the button "Save changes".
  4. Click the tab "Allow role overrides" (in Administration > Site administration > Users > Permissions > Define roles).
  5. Check the appropriate box(s) in the non-editing teacher row to set which role(s) they can override. Most likely it will just be the student role (you don't want non-editing teachers to be able to override managers), so check the box where the non-editing teacher row intersects with the student column.
  6. Click the button "Save changes".

If preferred, a new role for overriding permissions may be created and selected non-editing teachers assigned to it.

Overriding permissions for selected students

Sometimes a teacher will want to over ride permissions for selected students. Typically they will assign a student a role locally. For example, assign a student as a non-editing teacher. However, managers can override specific permission in a role. This does not create a new role. It modifies an existing specific role and affects all users assigned to that role in the context.

Sometimes the administrator (or someone with the permissions to) will create a new role. For example, the administrator will copy all the student permissions to a new role, then change specific permissions. The teacher then assigns specific students to this role without having to worry about checking off the correct role permissions.