Attention : vous consultez actuellement la documentation dédiée aux versions 1.x de Moodle. La documentation pour les versions 2.x de Moodle est consultable ici : Développement:Rôles, celle pour les versions 3.x de Moodle est consultable ici : Développement:Rôles et celle pour Moodle 4.x est consultable là : Développement:Rôles.

« Développement:Rôles » : différence entre les versions

De MoodleDocs
Aller à :navigation, rechercher
Aucun résumé des modifications
 
(18 versions intermédiaires par 3 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
{{Travail en cours}}
{{Travail en cours}}
{{Moodle 1.7}}
{{Moodle 1.7}}
'''Roles et capacités''' dans Moodle à partir de la version 1.7.
'''Rôles et capacités''' dans Moodle à partir de la version 1.7.


==Définitions==
==Définitions (rappels)==


Un 'rôle' identifie le statut d'un utilisateur dans un certain contexte. Par exemple : Enseignant, Etudiant et ''Modérateur de forum'' sont des exemples de rôles.
Un '''rôle''' identifie le statut d'un utilisateur dans un certain contexte. Par exemple : Enseignant, Étudiant et ''Modérateur de forum'' sont des exemples de rôles.


Une 'capacité' est la description d'une fonctionnalité particulière de Moodle. Les capacités peuvent être associées aux rôles. Par exemple, ''mod/forum:replypost'' est une 'capacité'.
Une '''capacité''' est la description d'une fonctionnalité particulière de Moodle. Les capacités peuvent être associées aux rôles. Par exemple, ''mod/forum:replypost'' est une 'capacité'.


Une 'permission' est une certaine valeur qui définit l'usage d'une certaine capacité par un rôle donné. Par exemple, autoriser ou empêcher.
Une '''permission''' est une certaine valeur qui définit l'usage d'une certaine capacité par un rôle donné. Par exemple, autoriser ou empêcher.


Un 'contexte' est un "endroit" dans Moodle, tel qu'un cours, un module d'activité, un bloc etc.
Un '''contexte''' est un "endroit" dans Moodle, tel qu'un cours, un module d'activité, un bloc etc.


==Le système antérieur de gestion des droits==
==Le système antérieur de gestion des droits==


Dans les versions antérieures à la v1.7, Moodle utilisait un ensemble de rôles prédéfinis c'est-à-dire, l'administrateur primaire, les administrateurs délégués, les chargés de cours, les enseignants éditeurs, les enseignants non éditeurs, les étudiants, et les invités. Pour chacun des rôles, les possibilités d'usage des différentes fonctionnalités de Moodle étaient fixées à l'avance par la programmation. Par exemple, le rôle étudiant permettait à un utilisateur de poster un devoir, mais pas de consulter le travail d'un autre utilisateur. Dans cette architecture, la définition des possibilités des utilisateurs était rigide. Si nous voulions faire en sorte qu'un étudiant particulier ou un certain groupe puisse consulter des devoirs dans un certain cours, nous étions obligé de lui attribuer un rôle d'enseignant dans ce cours, lui libérant peut-être un jeu de prérogatives bien trop étendu.
Dans les versions antérieures à la v1.7, Moodle utilisait un ensemble de rôles prédéfinis c'est-à-dire, l'administrateur primaire, les administrateurs délégués, les chargés de cours, les enseignants éditeurs, les enseignants non éditeurs, les étudiants, et les visiteurs anonymes. Pour chacun des rôles, les possibilités d'usage des différentes fonctionnalités de Moodle étaient fixées à l'avance par la programmation. Par exemple, le rôle étudiant permettait à un utilisateur de poster un devoir, mais pas de consulter le travail d'un autre utilisateur. Dans cette architecture, la définition des possibilités des utilisateurs était rigide. Si nous voulions faire en sorte qu'un étudiant particulier ou un certain groupe puisse consulter des devoirs dans un certain cours, nous étions obligé de lui attribuer un rôle d'enseignant dans ce cours, lui libérant peut-être un jeu de prérogatives bien trop étendu.


==Le nouveau système de rôles et capacités==
==Le nouveau système de rôles et capacités==
Ligne 21 : Ligne 21 :
A partir de la version v1.7, Moodle introduit un nouveau système de rôles et de capacités.
A partir de la version v1.7, Moodle introduit un nouveau système de rôles et de capacités.


Les rôles ont deux fonctions premières :
Le nouveau système permet à des utilisateurs autorisés de créer des rôles en nombre non limité. Un rôle est une liste de permissions attribuées à chacun des actions connues dans Moodle. Les rôles peuvent être attribués à des utilisateurs dans un certain contexte.
# définir une liste de permissions - la définition d'un rôle est commune à tous les contextes, mais ses permissions peuvent être altérées localement par un système de court-circuit. 
# remplacer l'ancien système d'inscription - l'assignation d'un rôle dans un contexte de cours est très similaire à l'ancienne procédure d'inscription.
 
Ce nouveau système permet à des utilisateurs autorisés de créer des rôles en nombre non limité (un enseignant par exemple).  
 
Un rôle est une liste de permissions attribuées à chacun des actions connues dans Moodle (par exemple, supprimer une discussion, ajouter une activité, etc.)
 
Les rôles peuvent être attribués à des utilisateurs dans un certain contexte (par exemple assigner Fred comme enseignant d'un certain cours).


Voici la liste des contextes possibles, listés du plus général au plus spécifique.  
Voici la liste des contextes possibles, listés du plus général au plus spécifique.  
Ligne 42 : Ligne 34 :
#CONTEXT_BLOCK        -- un bloc
#CONTEXT_BLOCK        -- un bloc


[[Image:Moodle-contexts-1.8.png|right|thumb|Diagramme des contextes dans Moodle 1.8, basé sur la discussion [[Talk:Roles_and_capabilities|text diagram by Martin Dougiamas]]. Clicker sur le diagramme pour une vue plus détaillée.]]
[[Image:Moodle-contexts-1.8.png|right|thumb|Diagramme des contextes dans Moodle 1.8, basé sur la discussion [[Talk:Roles_and_capabilities|text diagram by Martin Dougiamas]]. Cliquer sur le diagramme pour une vue plus détaillée.]]


Un utilisateur autorisé pourra attribuer un nombre de rôles arbitraire a chacun des utilisateurs connus dans un contexte donné, et ce pour chacun des contextes.
Un utilisateur autorisé pourra attribuer un nombre de rôles arbitraire a chacun des utilisateurs connus dans un contexte donné, et ce pour chacun des contextes.


Chaque capacité peut recevoir une des quatre valeurs de permissions :
Les valeurs de permissions disponibles sont :


#CAP_INHERIT : hérite de la permission du contexte supérieur
#CAP_INHERIT : hérite de la permission du contexte supérieur
#CAP_ALLOW : autorise l'usage (pour l'instant)
#CAP_ALLOW : autorise l'usage (pour l'instant)
#CAP_PREVENT : empèche l'activation de la capacité
#CAP_PREVENT : empêche l'activation de la capacité
#CAP_PROHIBIT : interdit toute réouverture plus locale du droit à l'usage
#CAP_PROHIBIT : interdit toute réouverture plus locale du droit à l'usage


Si aucune permission n'est définit pour une certaine capacité, alors la valeur de permission pour cette capacité est héritée du premier contexte immédiatement supérieur. Si une capacité se voyait attribuer plusieurs valeurs de permissions dans des contextes distincts, alors nous parlons de surcharge de permission par le contexte le plus local.
Si aucune permission n'est définie pour une certaine capacité, alors la valeur de permission pour cette capacité est héritée du premier contexte immédiatement supérieur. Si une capacité se voyait attribuer plusieurs valeurs de permissions dans des contextes distincts, alors nous parlons de surcharge de permission par le contexte le plus local.


Il est possible que, par le cumul des rôles, des permissions se trouvent en contradiction pour une capacité donnée. Ceci est résolu par l'application de la règle qui dit que le contexte le plus local l'emporte toujours, sauf si une règle d'interdiction est rencontrée à un niveau supérieur.
Il est possible que, par le cumul des rôles, des permissions se trouvent en contradiction pour une capacité donnée. Ceci est résolu par l'application de la règle qui dit que le contexte le plus local l'emporte toujours, sauf si une règle d'interdiction est rencontrée à un niveau supérieur.
Ligne 59 : Ligne 51 :
Par exemple, Marc est étudiant (rôle) dans un certain cours (contexte), ce qui lui permet d'écrire sur un WiKi. Mais Marc est aussi associé à un rôle Visiteur dans un contexte de module d'activité (pour un certain WiKi) qui l'empêche une écriture (lecture seule) dans ce WiKi. De ce fait, pour ce WiKi particulier, Marc ne pourra effectivement pas écrire quoi que ce soit dans ce WiKi car l'empéchement stipulé dans le contexte très localisé du module d'activité l'emporte.
Par exemple, Marc est étudiant (rôle) dans un certain cours (contexte), ce qui lui permet d'écrire sur un WiKi. Mais Marc est aussi associé à un rôle Visiteur dans un contexte de module d'activité (pour un certain WiKi) qui l'empêche une écriture (lecture seule) dans ce WiKi. De ce fait, pour ce WiKi particulier, Marc ne pourra effectivement pas écrire quoi que ce soit dans ce WiKi car l'empéchement stipulé dans le contexte très localisé du module d'activité l'emporte.


Si nous définissons une INTERDICTION sur une capacité, cela signifie que cette capacité ne pourra plus être autorisée par un quelconque contexte inférieur. L'interdiction gagne toujours. Par exemple, Jeff est associé à un rôle spécialement constitué pour des étudiants perturbateurs qui interdit toute écriture dans les forums (dans le contexte très général du site), mais dispose d'une ancienne affecation à un rôle de Facilitateur dans le "Forum de Sciences" du cours "Sciences et Mathématiques 101". Comme la règle d'interdiction prévaut, Jeff nepourra pas écrire dans le forum "Science forum" après sa mise à l'écart.
Si nous définissons une INTERDICTION sur une capacité, cela signifie que cette capacité ne pourra plus être autorisée par un quelconque contexte inférieur. L'interdiction gagne toujours. Par exemple, Jeff est associé à un rôle spécialement constitué pour des étudiants perturbateurs qui interdit toute écriture dans les forums (dans le contexte très général du site), mais dispose d'une ancienne affectation à un rôle de Facilitateur dans le "Forum de Sciences" du cours "Sciences et Mathématiques 101". Comme la règle d'interdiction prévaut, Jeff ne pourra pas écrire dans le forum "Science forum" après sa mise à l'écart.


Autorisation et empêchement s'annullent lorsqu'ils sont applicables à la même capacité dans le même contexte. Si une telle collision survient, c'est la permission du contexte immédiatement supérieur qui est applicable.
Autorisation et empêchement s'annulent lorsqu'ils sont applicables à la même capacité dans le même contexte. Si une telle collision survient, c'est la permission du contexte immédiatement supérieur qui est applicable.
 
Ceci paraît plus complexe qu'à l'usage en réalité. L'effet produit est un système très souple dans l'adaptation aux règles de gestion locales.


==Mise à jour à partir d'une version 1.6==
==Mise à jour à partir d'une version 1.6==


Une mise à jour "douce" conduit de la 1.6 à la 1.7. Les rôles existant dans l'ancien modèle(admin, enseignant, étudiant, etc), et les capacités statiques correspondantes sont automatiquement réencodées. Ceci est obtenu par la création de rôles prédéfinis (NdT : rôles dits "legacy" - "d'origine" en traduction littérale) au niveau site er cours, puis par la réassignation des utilisateurs préexistants à ces nouveaux rôles. Les rôles par défaut ont un jeu de permissions prédfinies pour un ensemble prédéfini de capacités, afin de produire un statut d'utilisateur conforme à ce qu'il était en 1.6. Sans aucune modification, Moodle réagira exactement de la même façon avant et après la mise à jour.
Une mise à jour "douce" conduit de la 1.6 à la 1.7. Les rôles existant dans l'ancien modèle (admin, enseignant, étudiant, etc), et les capacités statiques correspondantes sont automatiquement ré-encodées. Ceci est obtenu par la création de rôles prédéfinis (NdT : rôles dits "legacy" - "d'origine" en traduction littérale) au niveau site et cours, puis par la ré-assignation des utilisateurs préexistants à ces nouveaux rôles. Les rôles par défaut ont un jeu de permissions prédéfinies pour un ensemble prédéfini de capacités, afin de produire un statut d'utilisateur conforme à ce qu'il était en 1.6. Sans aucune modification, Moodle réagira exactement de la même façon avant et après la mise à jour.


===Administrateurs===
===Administrateurs===
Ligne 73 : Ligne 63 :
Les ''administrateurs'' se voient assignés le rôle "legacy" ''admin'' (Administrateur) du contexte ''site''.
Les ''administrateurs'' se voient assignés le rôle "legacy" ''admin'' (Administrateur) du contexte ''site''.


===Responsables de cours===
===Créateurs de cours===


Les ''responsables de cours'' se voient assignés le rôle "legacy" ''course creator'' (Responsable de cours) du contexte ''site''.
Les ''créateurs de cours'' se voient assignés le rôle "legacy" ''course creator'' (Créateur de cours) du contexte ''site''.


===Enseignants===
===Enseignants===
Ligne 81 : Ligne 71 :
Les ''enseignants'' se voient assignés le rôle "legacy" ''teacher'' (Enseignant) ou le rôle "Enseignant sans édition" dans tous les cours où ils avaient ce rôle.
Les ''enseignants'' se voient assignés le rôle "legacy" ''teacher'' (Enseignant) ou le rôle "Enseignant sans édition" dans tous les cours où ils avaient ce rôle.


===Etudiants===
===Étudiants===


Les ''étudiants'' se voient assignés le rôle "legacy" ''student'' (Etudiant) dans tous les cours où ils étaient inscrits.
Les ''étudiants'' se voient assignés le rôle "legacy" ''student'' (Étudiant) dans tous les cours où ils étaient inscrits.


===Invités===
===Visiteurs anonymes===


Il existe un seul et unique utilisateur non associé à un rôle du contexte site. Un rôle invité du contexte cours sera attribué à cet utilisateur pour chaque cours qui autorise l'entrée des invités. Le contrôle de l'accès invité dans un cours passe de trois à seulement deux options (les invités doivent fournir la clef - accès oui/non). Ce réglage impose la fourniture d'une clef de cours pour les invités.
Il existe un seul et unique utilisateur non associé à un rôle du contexte site. Un rôle visiteur anonyme du contexte cours sera attribué à cet utilisateur pour chaque cours qui autorise l'entrée des visiteurs anonymes. Le contrôle de l'accès visiteur anonyme dans un cours passe de trois à seulement deux options (les visiteurs anonymes doivent fournir la clef - accès oui/non). Ce réglage impose la fourniture d'une clef de cours pour les visiteurs anonymes.


==Capacités==
==Capacités==
Ligne 97 : Ligne 87 :
Toutes les capacités liées à des fonctionnalités du noyau de Moodle commencent par le préfixe 'moodle/'. Le mot qui suit désigne le type de capacité, et le dernier désigne le nom de la capacité elle-même. Les capacités du noyau de Moodle sont définies dans le fichier lib/db/access.php.
Toutes les capacités liées à des fonctionnalités du noyau de Moodle commencent par le préfixe 'moodle/'. Le mot qui suit désigne le type de capacité, et le dernier désigne le nom de la capacité elle-même. Les capacités du noyau de Moodle sont définies dans le fichier lib/db/access.php.


#moodle/legacy:guest - Les capcités "legacy" existent pour la transition entre l'ancien schéma de rôles et le nouveau schéma de la version 1.7.
#moodle/legacy:guest - Les capacités "legacy" existent pour la transition entre l'ancien schéma de rôles et le nouveau schéma de la version 1.7.
#moodle/legacy:student
#moodle/legacy:student
#moodle/legacy:teacher
#moodle/legacy:teacher
Ligne 106 : Ligne 96 :
#moodle/site:config - applicable dans admin/index.php et config.php (elle sera peut-être subdivisée dans l'avenir) : 1)admin/config.php 2)admin/configure.php 3)blocks/admin/block_admin.php load_content_for_site()
#moodle/site:config - applicable dans admin/index.php et config.php (elle sera peut-être subdivisée dans l'avenir) : 1)admin/config.php 2)admin/configure.php 3)blocks/admin/block_admin.php load_content_for_site()
#moodle/site:readallmessages - capacité de lire tous les messages et les historiques
#moodle/site:readallmessages - capacité de lire tous les messages et les historiques
#moodle/site:approvecourse - capacité d'approuvé un cours en attente (demande de cours)
#moodle/site:approvecourse - capacité d'approuver un cours en attente (demande de cours)
#moodle/site:manageblocks - capacité d'ajouter/supprimer/modifier des blocs existants.(contextes site et cours seulement) : 1)_add_edit_controls moodleblock.class.php  
#moodle/site:manageblocks - capacité d'ajouter/supprimer/modifier des blocs existants.(contextes site et cours seulement) : 1)_add_edit_controls moodleblock.class.php  
#moodle/site:backup - capacité de sauvegarder un cours : 1)course/category.php 2)block_admin.php
#moodle/site:backup - capacité de sauvegarder un cours : 1)course/category.php 2)block_admin.php
Ligne 120 : Ligne 110 :
#moodle/blog:view - lire les blogs (dans les contextes site ou cours)
#moodle/blog:view - lire les blogs (dans les contextes site ou cours)
#moodle/blog:create - capacité de poster dans les blogs (à un niveau site seulement)
#moodle/blog:create - capacité de poster dans les blogs (à un niveau site seulement)
#moodle/blog:manageofficialtags - capacité de créeer/supprimer des marqueurs officiels que les autres utilisateurs peuvent utiliser dans les blogs (niveau site seulement)
#moodle/blog:manageofficialtags - capacité de créer/supprimer des marqueurs officiels que les autres utilisateurs peuvent utiliser dans les blogs (niveau site seulement)
#moodle/blog:managepersonaltags - capacité de supprimer de marqueurs personnalisés que les autres utilisateurs pouvaient utiliser (niveau site seulement) Note : les utilisateurs peuvent toujours ajouter des marqueurs personnalisés. Cette capacité ne devrait pas être permise par défaut pour les étudiants.
#moodle/blog:managepersonaltags - capacité de supprimer de marqueurs personnalisés que les autres utilisateurs pouvaient utiliser (niveau site seulement) Note : les utilisateurs peuvent toujours ajouter des marqueurs personnalisés. Cette capacité ne devrait pas être permise par défaut pour les étudiants.
#moodle/blog:manageentries - capacité de modifier/supprimer des entrées de blog (niveau site seulement)
#moodle/blog:manageentries - capacité de modifier/supprimer des entrées de blog (niveau site seulement)
Ligne 154 : Ligne 144 :
#moodle/user:create - capacité à créer un utilisateur : 1) user/edit.php
#moodle/user:create - capacité à créer un utilisateur : 1) user/edit.php
#moodle/user:delete - capacité à supprimer un utilisateur : 1) admin/user.php
#moodle/user:delete - capacité à supprimer un utilisateur : 1) admin/user.php
moodle/user:readuserblogs - capacité à voir les entrées de blog
#moodle/user:readuserblogs - capacité à voir les entrées de blog
#moodle/user:update - capacité à modifier les réglages utilisateur : 1) user/edit.php
#moodle/user:update - capacité à modifier les réglages utilisateur : 1) user/edit.php
#moodle/user:viewdetails - capacité à voir des données personnelles (par exemple, le nom et le photo).
#moodle/user:viewdetails - capacité à voir des données personnelles (par exemple, le nom et le photo).
#moodle/user:viewhiddendetails - capacité à voir des propriétés cachées des utilisateurs.
#moodle/user:viewhiddendetails - capacité à voir des propriétés cachées des utilisateurs.
#moodle/calendar:manageownentries - capacité à créer/supprimer/modifier des événements privés.  
#moodle/calendar:manageownentries - capacité à créer/supprimer/modifier des évènements privés.  
#moodle/calendar:manageentries - créer/supprimer/modifier des événements.
#moodle/calendar:manageentries - créer/supprimer/modifier des évènements.
#moodle/role:assign - capacité à assigner des rôles à des utilisateurs.
#moodle/role:assign - capacité à assigner des rôles à des utilisateurs.
#moodle/role:override - capacité à court-circuiter des rôles (dépend du contexte).
#moodle/role:override - capacité à court-circuiter des rôles (dépend du contexte).
Ligne 179 : Ligne 169 :
Les capacités au niveau module sont cachées dans une table de la base de données lorsqu'un module est installé ou lorsqu'il est remis à jour. Pour que les définitions de capacités soient mises à jour suite à une modification du module, il suffit d'augmenter le numéro de version du module pour déclencher les fonctions de mise à jour automatiques.
Les capacités au niveau module sont cachées dans une table de la base de données lorsqu'un module est installé ou lorsqu'il est remis à jour. Pour que les définitions de capacités soient mises à jour suite à une modification du module, il suffit d'augmenter le numéro de version du module pour déclencher les fonctions de mise à jour automatiques.


Les convenstions de nommage des capacités de contexte module ou bloc conduisent à l'utilisation du schéma 'mod/mod_name:capability'. La partie à gauche du double point est le chemin d'accès au code du module dans l'installation de Moodle. Les capacités d'un module sont définies dans le fichier standard mod/mod_name/db/access.php.
Les conventions de nommage des capacités de contexte module ou bloc conduisent à l'utilisation du schéma 'mod/mod_name:capability'. La partie à gauche du double point est le chemin d'accès au code du module dans l'installation de Moodle. Les capacités d'un module sont définies dans le fichier standard mod/mod_name/db/access.php.


#Assignment
#Assignment
Ligne 312 : Ligne 302 :
#social_activities
#social_activities


===Questions===
I am adding question categories here because they seem to have been forgotten in the whole scheme of things since having been removed from the quiz module itself. I've made a suggestion on how these could be handled in [http://www.moodle.org/bugs/bug.php?op=show&bugid=6118&pos= bug 6118].


See [http://moodle.org/mod/forum/discuss.php?d=51143 this forum thread] for a discussion about the current problems wth publishing question categories.[[User:Tim Hunt|Tim Hunt]] 18:50, 8 August 2006 (WST)


==API==
==API==
Ligne 338 : Ligne 325 :


   $context = get_context_instance(CONTEXT_MODULE, $cm->id);
   $context = get_context_instance(CONTEXT_MODULE, $cm->id);
* Une fois le contexte connu, et à chasue fois que vous voulez déterminer si l'utilisateur a le droit de faire ceci ou celà, vous appelerez la fonction has_capability() comme ceci :
* Une fois le contexte connu, et à chaque fois que vous voulez déterminer si l'utilisateur a le droit de faire ceci ou celà, vous appelerez la fonction has_capability() comme ceci :
     if (!has_capability('mod/forum:viewforum', $context)) {
     if (!has_capability('mod/forum:viewforum', $context)) {
         print_error('nopermissiontoviewforum');
         print_error('nopermissiontoviewforum');
Ligne 348 : Ligne 335 :
* Notez que des paramètres supplémentaires peuvent être définis pour paramétrer le message d'erreur, en l'absence desquels le message standard "No permissions" est affiché, avec une liste des noms de permissions manquantes.
* Notez que des paramètres supplémentaires peuvent être définis pour paramétrer le message d'erreur, en l'absence desquels le message standard "No permissions" est affiché, avec une liste des noms de permissions manquantes.


Pour se conformer au nouveau système de rôles, tous les appels antérieurs à isadmin(), iscoursecreator(), isteacheredit(), isteacher(), isstudent(), et isguest() devrontêtre remplacés par des appels à has_capability() ou require_capability(). Cependant, ces fonctions continueront à exister par souci de compatibilité avec des modules codés "à l'ancienne", mais leur fonctionnement s'appuie désormais sur les rôles "legacy".
Pour se conformer au nouveau système de rôles, tous les appels antérieurs à isadmin(), iscoursecreator(), isteacheredit(), isteacher(), isstudent(), et isguest() devront être remplacés par des appels à has_capability() ou require_capability(). Cependant, ces fonctions continueront à exister par souci de compatibilité avec des modules codés "à l'ancienne", mais leur fonctionnement s'appuie désormais sur les rôles "legacy".


==Metacourss==
==Rôles et Métacours==


Le copportement des métacours a été légèrement modifié dans Moodle 1.7, en ce sens que s'il ne synchronisait que l'inscription des étudiants entre le métacours et le cours descendant, la synchronisation s'étend désormais à TOUS les rôles. Les enseignants et autres utilisateurs conserveront un rôle identique dans le métacours et dans le cours descendant. Techniquement, le métacours synchronise toutes ses attributions de rôle du contexte CONTEXT_COURSE avec son cours descendant ; la seule exception à ce procédé concerne les utilisateurs disposant de la capacité moodle/course:managemetacourse, qui n'ont qu'une synchronisation ascendante : ces utilisateurs ne seront pas désinscrits du métacours s'ils sont enlevés du contexte supérieur ou su le métacours est déconnecté de son cours ascendant.
Le comportement des métacours a été légèrement modifié dans Moodle 1.7, en ce sens que s'il ne synchronisait que l'inscription des étudiants entre le métacours et le cours descendant, la synchronisation s'étend désormais à TOUS les rôles. A partir de Moodle 1.8, on peut choisir pour quel rôle la synchronisation doit être faite. Les enseignants et autres utilisateurs conserveront un rôle identique dans le métacours et dans le cours descendant. Techniquement, le métacours synchronise toutes ses attributions de rôle du contexte CONTEXT_COURSE avec son cours descendant ; la seule exception à ce procédé concerne les utilisateurs disposant de la capacité moodle/course:managemetacourse, qui n'ont qu'une synchronisation ascendante : ces utilisateurs ne seront pas désinscrits du métacours s'ils sont enlevés du contexte supérieur ou su le métacours est déconnecté de son cours ascendant.


Pour importer d'autres cours dans un métacours vous devez disposer de la capacité moodle/course:managemetacourse. Vous ne pourrez ajouter manuellement des utilisateurs que si vous disposez de cette capacité moodle/course:managemetacourse, tous les autres participants proviennent de la synchronisation avec le cours descendant - si vous essayez d'inscrire un utilisateur sans disposer de cette capacité, un message d'erreur vous est signifié. Un message d'erreur similaire est présenté si vous essayez de désinscrire un utilisateur d'un métacours alors qu'il reste inscrit dans le cours descendant.
Pour importer d'autres cours dans un métacours vous devez disposer de la capacité moodle/course:managemetacourse. Vous ne pourrez ajouter manuellement des utilisateurs que si vous disposez de cette capacité moodle/course:managemetacourse, tous les autres participants proviennent de la synchronisation avec le cours descendant - si vous essayez d'inscrire un utilisateur sans disposer de cette capacité, un message d'erreur vous est signifié. Un message d'erreur similaire est présenté si vous essayez de désinscrire un utilisateur d'un métacours alors qu'il reste inscrit dans le cours descendant.


Exemple de situation pour une plate-forme typique :
Exemple de situation pour une plate-forme typique :
* Le gestionnaire d'un méta cours dispose de la capacité moodle/course:managemetacourse adans le contexte site ou cours.
* Le gestionnaire d'un méta cours dispose de la capacité moodle/course:managemetacourse dans le contexte site ou cours.
* Les étudiants sont enregistrés dans divers cours descendants.
* Les étudiants sont enregistrés dans divers cours descendants.
* Les enseignants sont enregistrés dans comme enseignants dans des cours descendants distincts.
* Les enseignants sont enregistrés dans comme enseignants dans des cours descendants distincts.


==Problem areas we are working on ==
===Student view===
The "Student view" button has been removed completely.
If there is time and a secure way can be found, it will be replaced by a menu to let the user assume a temporary role in the context of that course.
===Teacher forum===
Teacher forums were always a curious exception to normal forums, as they were not part of a course as such, and were not backed up.
We're taking the opportunity to rectify this.  The upgrade converts teacher forums with content to normal forums in section 0 of the course, and ensures that only teachers can access them.  If the teacher forum had not been used in the course then it's not converted and will just dissappear.
===Enrolment plugins===
====Process of logging in====
# load_user_capability() is called to load all the capabilities
# check_enrolment_plugins() is called at the top of load_user_capability() to check all the enrolment plugins.
# For each active plugin:
##Check for setup_enrolments($user) and run it.  This function will do all the processing needed to assign or unassign roles from the current user.
# load_user_capability() continues and loads up all the roles
# load_defaultuser_role() is called to add default site permissions (all users)
====Process of checking access to a course====
require_login($course->id) is called by the script and has logic like this:
# Is the user a guest at site level?
## Yes: Does the course allow guests?
### Yes: return true (and further capabilities are checked by the script)
### No:  send the user to course/enrol.php for enrolment
## No: continue below


# Does the user have moodle/course:view in that (course) context?
## Yes: then they can enter (and further capabilities are checked by the script)
##  No: is guest access allowed on the course?
### Yes: assign temporary guest role to that user for that context (in session cache).
### No: send the user to course/enrol.php for enrolment.


====Process of enrolling====
==Rôles typiques, scénarios et prospectives==


(more soon)
Cette section présente un certain nombre de scénarios d'usage des rôles que nous souhaiterions pouvoir prendre en compte. Notez que ces rôles ne sont pas nécessairement tous possibles dans l'implémentation actuelle.


==Scenario brainstorming==
===Etudiant===
Rôle trivial.


This section is for brainstorming some example roles that we would like to support. Note some of these *may* not be possible in 1.7.
===Concepteur de sites===
Un rôle pour des personnes responsables de l'apparence du site, mais ne disposant pas de droits d'administration complets ? On pense alors à une possibilité d'éditer des informations relatives aux thèmes en ligne, plutôt que leur modification par accès FTP. Les capacités adéquates seraient
#caneditlogos - capacité à changer le(s) logo(s).
#caneditcss - capacité à modifier les clauses de style.
#candeditlevelatwhichthemeapplies - capacité à modifier les informations relatives à l'application des thèmes.


===Student===
===Conseiller en ingénierie pédagogique===
Obviously.
 
===Site Designers===
Is there a role for people involved in how the site looks but not full administrators? Thinking here of online control of themes rather than FTP theme uploading. But in either case they caneditlogos, caneditcss, candeditlevelatwhichthemeapplies.
 
===Educational Authority Adviser===
Someone who would want to browse the site and may be asked to comment or contribute to particular discussions or developments in school. Access for this role would be controlled by the school in the case of school level moodles but may be different if there were to be a Local Authority wide Moodle.
Someone who would want to browse the site and may be asked to comment or contribute to particular discussions or developments in school. Access for this role would be controlled by the school in the case of school level moodles but may be different if there were to be a Local Authority wide Moodle.


===Educational Inspector===
===Inspecteur pédagogique===
Someone who will visit the site to verify the school's self review that comments on home school relationships, extending the classroom etc. They may want to see summaries of usage and reports from surveys garnering parent and pupil views.
Someone who will visit the site to verify the school's self review that comments on home school relationships, extending the classroom etc. They may want to see summaries of usage and reports from surveys garnering parent and pupil views.


===Second Marker / Moderator===
===Correcteur / Modérateur===
A teacher within ths site that has access to assignments and quizzes from another teacher's course for second marking purposes. This may need additional functionality adding to the assignment module so that two sets of grades/feedback can be given to one set of assignments.
A teacher within ths site that has access to assignments and quizzes from another teacher's course for second marking purposes. This may need additional functionality adding to the assignment module so that two sets of grades/feedback can be given to one set of assignments.


===Peer observer of teaching===
===Observateur du processus et des pratiques pédagogiques===
Many institutions encourage peer observation of teaching, to encourage reflection on practice. In online environments this will be similar to moderation or inspection. The peer observer would need to be able to experience the course "as a student", but also to be able to view summaries of usage, transcripts of interactions (forums/surveys/polls etc), grades assigned (e.g. in assignments).
Many institutions encourage peer observation of teaching, to encourage reflection on practice. In online environments this will be similar to moderation or inspection. The peer observer would need to be able to experience the course "as a student", but also to be able to view summaries of usage, transcripts of interactions (forums/surveys/polls etc), grades assigned (e.g. in assignments).


===External Examiner===
===Examinateur externe===
Has all the rights of inspectors, but would also need to be able to review assignments and feedback, view forums, glossaries etc. However, would not want to post, feedback onto the site at all.
Has all the rights of inspectors, but would also need to be able to review assignments and feedback, view forums, glossaries etc. However, would not want to post, feedback onto the site at all.


Ligne 452 : Ligne 399 :
There is some concern that children's forum contributions etc may be constrained if their parents are able to read all that they write; this may be particularly problematic in areas such as Personal, Social and Health Education (PSHE), where some schools may choose to use obfuscated usernames.
There is some concern that children's forum contributions etc may be constrained if their parents are able to read all that they write; this may be particularly problematic in areas such as Personal, Social and Health Education (PSHE), where some schools may choose to use obfuscated usernames.


===Manager===
===Gestionnaire===
''Please add text here...''
''à développer''


===Weekly Seminar Leader===
===Coordinateur de séminaire===
''In a university seminar, typically 8-15 students in their 3rd/4th year, each student is responsible for leading one topic in a study series.  I ask each student to research 5-10 resources, then give a powerpoint presentation to the other students.  This is followed by an in-class discussion and then online homework.  The homework involves some fun quiz questions and then some reflective journal questions.  I ask each seminar leader to prepare the quiz questions and journal questions as well as their presentation.  To do that, I would like to assign activity-making/authoring roles to the student--either for a short period, or for duration of the whole course.  Thus "Allow Quiz Authoring Role" or "Allow Assignment Authoring Role" at the course level or, if possible, even the Topic level (in a topic or week format course) would be important.''
''In a university seminar, typically 8-15 students in their 3rd/4th year, each student is responsible for leading one topic in a study series.  I ask each student to research 5-10 resources, then give a powerpoint presentation to the other students.  This is followed by an in-class discussion and then online homework.  The homework involves some fun quiz questions and then some reflective journal questions.  I ask each seminar leader to prepare the quiz questions and journal questions as well as their presentation.  To do that, I would like to assign activity-making/authoring roles to the student--either for a short period, or for duration of the whole course.  Thus "Allow Quiz Authoring Role" or "Allow Assignment Authoring Role" at the course level or, if possible, even the Topic level (in a topic or week format course) would be important.''


===Mentor/Mentee===
===Participant non-enseignant à l'élaboration de la stratégie d'évaluation===
''Please add text here...''
 
===Community-Designed Rating Criteria===
''The gradebook tends to be the domain of the teacher.  What if community/peer ratings/marks could also be entered there? What if peer assessment criteria could be designed by the students, not just the teacher?''
''The gradebook tends to be the domain of the teacher.  What if community/peer ratings/marks could also be entered there? What if peer assessment criteria could be designed by the students, not just the teacher?''


===Visitor===
===Visiteur===


This would be a role whereby one could allow a visitor to visit one's classroom. This might be a colleague interested in seeing your course, or a journalist who might be writing an article about one's site. They should not be able to see the names of any students anywhere (eg recent activity, forum posts) for privacy reasons. They should be able to try out things like quizzes, and lessons but no grades would be recorded (like in teacher preview mode). They would not be able to participate in choices and forums but could view them. It would be read only in a way like former-student role below but without access to a particular student's records that former student role would grant.
This would be a role whereby one could allow a visitor to visit one's classroom. This might be a colleague interested in seeing your course, or a journalist who might be writing an article about one's site. They should not be able to see the names of any students anywhere (eg recent activity, forum posts) for privacy reasons. They should be able to try out things like quizzes, and lessons but no grades would be recorded (like in teacher preview mode). They would not be able to participate in choices and forums but could view them. It would be read only in a way like former-student role below but without access to a particular student's records that former student role would grant.


===Guest Speaker===
===Intervenant invité===


This role would be similar to the Visitor role above, but would allow seeing student names, and also allow both reading and posting to a specific forum or forums. We often have "guest speakers" who read and respond to student forum posts. Right now we have to add them as students, which isn't ideal.
This role would be similar to the Visitor role above, but would allow seeing student names, and also allow both reading and posting to a specific forum or forums. We often have "guest speakers" who read and respond to student forum posts. Right now we have to add them as students, which isn't ideal.


===Former Student===
===Ancien===
This role would be of particular use for courses with rolling enrollments. This role would be one where a student had completed all of the requirements of a course (ie assignments, quizzes etc.) but wished to have continued access to the course material for review or consultation. The key factor is that one would give access to the completed student to the notes he read, his work and the teacher's comments on it, but he would not be allowed to do anything that would take up the teacher's time. In other words, a sort-of read-only access to the course. How forums, which might contain pertinent information and would continue to grow, would be handled is a question. Perhaps the student would be shown only what was in the forums at the time he completed the course. He would not be allowed to see any new posts or add any himself. Same thing for database and glossary entries. In other words, a snapshot of the course at the time his regular enrollment ended. He shouldn't be able to see the names or profiles of any newly enrolled students for privacy reasons-hence the restrictions on forum access. One issue that would have to be dealt with would be changes to existing modules-such as resources. Does the student get access to the module as it was or as it is? We have no versioning of resources in Moodle so this would be a problem. What about a teacher changing a quiz question so that the answer is different? What would a former student see?
This role would be of particular use for courses with rolling enrollments. This role would be one where a student had completed all of the requirements of a course (ie assignments, quizzes etc.) but wished to have continued access to the course material for review or consultation. The key factor is that one would give access to the completed student to the notes he read, his work and the teacher's comments on it, but he would not be allowed to do anything that would take up the teacher's time. In other words, a sort-of read-only access to the course. How forums, which might contain pertinent information and would continue to grow, would be handled is a question. Perhaps the student would be shown only what was in the forums at the time he completed the course. He would not be allowed to see any new posts or add any himself. Same thing for database and glossary entries. In other words, a snapshot of the course at the time his regular enrollment ended. He shouldn't be able to see the names or profiles of any newly enrolled students for privacy reasons-hence the restrictions on forum access. One issue that would have to be dealt with would be changes to existing modules-such as resources. Does the student get access to the module as it was or as it is? We have no versioning of resources in Moodle so this would be a problem. What about a teacher changing a quiz question so that the answer is different? What would a former student see?


===Alumnus=== An ALUMNUS should be able to search for all other ALUMNI of the school, interact with them and be enrolled in a seperate course - which is like a META course with all the content of his learning and interaction - as well as capabilities to be a part of this ALUMNI only course.  All the teachers of courses during school years should automatically be a part of the ALUMNI course .. which means when an ALUMNUS is enrolled in a course, the original teachers of all his courses get enrolled ?  --[[User:Anil Sharma|Anil Sharma]] 20:54, 15 July 2006 (WST)
===Alumnus=== An ALUMNUS should be able to search for all other ALUMNI of the school, interact with them and be enrolled in a seperate course - which is like a META course with all the content of his learning and interaction - as well as capabilities to be a part of this ALUMNI only course.  All the teachers of courses during school years should automatically be a part of the ALUMNI course .. which means when an ALUMNUS is enrolled in a course, the original teachers of all his courses get enrolled ?  --[[User:Anil Sharma|Anil Sharma]] 20:54, 15 July 2006 (WST)


===Librarian===
===Bibliothécaire/Documentaliste===


Reference Librarians have an active role in most of the courses taught at some schools such as Earlham College (with Bibliographic Instruction). The Librarian role within Moodle could encompass default read access to all courses (unless prohibited by course teacher) and read access to all components of the course unless access is barred (again by teacher). The Librarians would also perhaps have a block called perhaps Reference Services or Reference Desk with write access where they could deposit resources. Also this block might have a chat applet whereby enrolled students could chat to the Reference Librarian on duty about their bibliographic research needs.
Reference Librarians have an active role in most of the courses taught at some schools such as Earlham College (with Bibliographic Instruction). The Librarian role within Moodle could encompass default read access to all courses (unless prohibited by course teacher) and read access to all components of the course unless access is barred (again by teacher). The Librarians would also perhaps have a block called perhaps Reference Services or Reference Desk with write access where they could deposit resources. Also this block might have a chat applet whereby enrolled students could chat to the Reference Librarian on duty about their bibliographic research needs.
Ligne 483 : Ligne 427 :
In schools there is often a book review system. This may be covered by the lending system database but may not in which case a librarian may neeed to have a course area they can create a database template to handle the reviews in which case they may have a normal teacher style role? Off topic but course an integration with common schools database systems would be great.
In schools there is often a book review system. This may be covered by the lending system database but may not in which case a librarian may neeed to have a course area they can create a database template to handle the reviews in which case they may have a normal teacher style role? Off topic but course an integration with common schools database systems would be great.


===Teacher===
===Enseignant===


Teachers should have read access to other Teacher's courses unless explictly prohibited. They should be able to set parts of their own course to be totally private (perhaps even to admin?). Just as each activity can currently be set to have group access, each activity could have a permissions field. Teachers could set default permissions for all activities on their course (eg they might disallow Librarian access for example) and then change the access permission for an individual activity.  
Teachers should have read access to other Teacher's courses unless explictly prohibited. They should be able to set parts of their own course to be totally private (perhaps even to admin?). Just as each activity can currently be set to have group access, each activity could have a permissions field. Teachers could set default permissions for all activities on their course (eg they might disallow Librarian access for example) and then change the access permission for an individual activity.  
Ligne 491 : Ligne 435 :
I would take issue with "teachers should have read access to other teacher's courses unless explicitly prohibited." This is a violation of the students' privacy as how they perform and what they do in one class isn't the business of another teacher. Moreover, in the real world a teacher wouldn't suddenly go sit in on a colleague's class without asking permission first. I would not have appreciated such an invasion of privacy as either a teacher or a student. It could be an option, but shouldn't be default.--[[User:N Hansen|N Hansen]] 19:54, 12 June 2006 (WST)
I would take issue with "teachers should have read access to other teacher's courses unless explicitly prohibited." This is a violation of the students' privacy as how they perform and what they do in one class isn't the business of another teacher. Moreover, in the real world a teacher wouldn't suddenly go sit in on a colleague's class without asking permission first. I would not have appreciated such an invasion of privacy as either a teacher or a student. It could be an option, but shouldn't be default.--[[User:N Hansen|N Hansen]] 19:54, 12 June 2006 (WST)


===Community Education Tutors/Trainers===
===Tuteurs===
Teachers may be community adult education trainers making use of a school moodle so must only have access to their courses unless given access elsewhere. They would not necessarily get the default teacher privileges.
Teachers may be community adult education trainers making use of a school moodle so must only have access to their courses unless given access elsewhere. They would not necessarily get the default teacher privileges.


===Secretary/Student Worker===
===Secrétaire/Assistant-étudiant===


We often have faculty who want their departmental secretary or student worker to scan and upload files and perhaps create resources. Currently they have to be given teacher access to the course. This is dangerous from a FERPA standpoint since they could easily get access to grades.
We often have faculty who want their departmental secretary or student worker to scan and upload files and perhaps create resources. Currently they have to be given teacher access to the course. This is dangerous from a FERPA standpoint since they could easily get access to grades.


===Teaching Assistant===
===Assistant pédagogique===


Our Faculty frequently have undergraduate students acting as Teaching Assistants. These students need to be able to add resources, create assignments, and possibly grade assignments. However, due to FERPA they cannot have access to other students' overall grade information. I think the requirements here are slightly different than those of Secretary/Student Worker
Our Faculty frequently have undergraduate students acting as Teaching Assistants. These students need to be able to add resources, create assignments, and possibly grade assignments. However, due to FERPA they cannot have access to other students' overall grade information. I think the requirements here are slightly different than those of Secretary/Student Worker


===Student - FERPA rights===
===Support utilisateur===


A student that has asserted their FERPA rights to non-disclosure. Typically includes not publishing their name
Help desk agents that have read access for the purposes of trouble shooting. Some care in placing this role within a hierarchy of inheritance is needed, full access will be problematic with FERPA.
in any public place.  Could include this student only being seen with an "alias" within course spaces. Is this an attribute rather
than a role?


===Help Desk===
===Administrateurs et administrateurs délégués===
 
Help desk agents that have read access for the purposes of trouble shooting.  Some care in placing this role within a hierarchy
of inheritance is needed, full access will be problematic with FERPA.
 
===Admin - Catgory based===


Basically a person in between full Admin and Creator that has the permissions of an Admin but only with respect to courses and students. Currently a Creator has permissions site-wide which does not always meet the requirements of a given organisation (e.g. Department A may not be happy that a person from Department B can create/modify courses within Department A's area). The ability to designate a Creator within a specific category would allow areas to be set up for a faculty/department/organisation and allow the Admin for that area to create/delete courses, upload users, add site-wide entries to the calendar etc.
Basically a person in between full Admin and Creator that has the permissions of an Admin but only with respect to courses and students. Currently a Creator has permissions site-wide which does not always meet the requirements of a given organisation (e.g. Department A may not be happy that a person from Department B can create/modify courses within Department A's area). The ability to designate a Creator within a specific category would allow areas to be set up for a faculty/department/organisation and allow the Admin for that area to create/delete courses, upload users, add site-wide entries to the calendar etc.


===Process Roles===
===Rôles dans une procédure multi-rôle===


organising the learning process for a group you wish to have the choice to place students in differnt roles: examples of this are:
organising the learning process for a group you wish to have the choice to place students in differnt roles: examples of this are:
Ligne 525 : Ligne 462 :
* Give a student the rights to create the section content of next week (and only that week..)
* Give a student the rights to create the section content of next week (and only that week..)


==Things to finish for 1.7 Beta==
==Voir également==
'''18 Sept 2006'''
 
#Remove core references to user_student, user_teacher, user_admin, user_coursecreator tables.  [Yu]
#Address function: isteacher, isadmin, isstudent [Yu]
#Remove "view" capabilities from all modules unless required [Vy]
#Remove all old references from remaining Blocks [Vy]
#Metacourses [Skodak]
#Add risks to GUI[Skodak]
#Enrolment plugins  [Martin and Alastair]
#[[Development:Stats_roles_1.7|Statistics]] [Penny]
#Fix Loginas
#Add category-level assigns [Yu]
#[[Development:Backup_roles_1.7|Backups]] [Eloy?]
 
 


==See also==
*[[Développement:Renforcement du système de rôles]]
 
*[[Développement:Rôles et modules]]
*[[Development:Hardening new Roles system]]
**Discussions clef pour la construction du système de rôles (en anglais) :
*[[Development:Roles and modules]]
*Using Moodle course:
**[http://moodle.org/mod/forum/view.php?f=941 Roles and Capabilities forum]
**Key discussions at Using Moodle forums:
***[http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture]
***[http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture]
***[http://moodle.org/mod/forum/discuss.php?d=56302#256313 An example of admin roles as set in the database]
***[http://moodle.org/mod/forum/discuss.php?d=56302#256313 An example of admin roles as set in the database]


[[Category:Developer|Roles]]
[[Category:Développeur]]
[[Category:Roles]]
[[Category:Rôles]]
 
[[en:Development:Roles]]

Dernière version du 12 novembre 2009 à 09:18

Remarque : cet article est en cours de rédaction. N'hésitez pas à le compléter. Veuillez utiliser la page de discussion pour vos recommandations et suggestions d'améliorations.


Moodle1.7


Rôles et capacités dans Moodle à partir de la version 1.7.

Définitions (rappels)

Un rôle identifie le statut d'un utilisateur dans un certain contexte. Par exemple : Enseignant, Étudiant et Modérateur de forum sont des exemples de rôles.

Une capacité est la description d'une fonctionnalité particulière de Moodle. Les capacités peuvent être associées aux rôles. Par exemple, mod/forum:replypost est une 'capacité'.

Une permission est une certaine valeur qui définit l'usage d'une certaine capacité par un rôle donné. Par exemple, autoriser ou empêcher.

Un contexte est un "endroit" dans Moodle, tel qu'un cours, un module d'activité, un bloc etc.

Le système antérieur de gestion des droits

Dans les versions antérieures à la v1.7, Moodle utilisait un ensemble de rôles prédéfinis c'est-à-dire, l'administrateur primaire, les administrateurs délégués, les chargés de cours, les enseignants éditeurs, les enseignants non éditeurs, les étudiants, et les visiteurs anonymes. Pour chacun des rôles, les possibilités d'usage des différentes fonctionnalités de Moodle étaient fixées à l'avance par la programmation. Par exemple, le rôle étudiant permettait à un utilisateur de poster un devoir, mais pas de consulter le travail d'un autre utilisateur. Dans cette architecture, la définition des possibilités des utilisateurs était rigide. Si nous voulions faire en sorte qu'un étudiant particulier ou un certain groupe puisse consulter des devoirs dans un certain cours, nous étions obligé de lui attribuer un rôle d'enseignant dans ce cours, lui libérant peut-être un jeu de prérogatives bien trop étendu.

Le nouveau système de rôles et capacités

A partir de la version v1.7, Moodle introduit un nouveau système de rôles et de capacités.

Le nouveau système permet à des utilisateurs autorisés de créer des rôles en nombre non limité. Un rôle est une liste de permissions attribuées à chacun des actions connues dans Moodle. Les rôles peuvent être attribués à des utilisateurs dans un certain contexte.

Voici la liste des contextes possibles, listés du plus général au plus spécifique.

  1. CONTEXT_SYSTEM -- l'intégralité du site
  2. CONTEXT_PERSONAL -- vous-même (l'utilisateur courant)
  3. CONTEXT_USER -- un utilisateur particulier
  4. CONTEXT_COURSECAT -- une catégorie de cours
  5. CONTEXT_COURSE -- un cours
  6. CONTEXT_GROUP -- un groupe
  7. CONTEXT_MODULE -- un module d'activités
  8. CONTEXT_BLOCK -- un bloc
Diagramme des contextes dans Moodle 1.8, basé sur la discussion text diagram by Martin Dougiamas. Cliquer sur le diagramme pour une vue plus détaillée.

Un utilisateur autorisé pourra attribuer un nombre de rôles arbitraire a chacun des utilisateurs connus dans un contexte donné, et ce pour chacun des contextes.

Les valeurs de permissions disponibles sont :

  1. CAP_INHERIT : hérite de la permission du contexte supérieur
  2. CAP_ALLOW : autorise l'usage (pour l'instant)
  3. CAP_PREVENT : empêche l'activation de la capacité
  4. CAP_PROHIBIT : interdit toute réouverture plus locale du droit à l'usage

Si aucune permission n'est définie pour une certaine capacité, alors la valeur de permission pour cette capacité est héritée du premier contexte immédiatement supérieur. Si une capacité se voyait attribuer plusieurs valeurs de permissions dans des contextes distincts, alors nous parlons de surcharge de permission par le contexte le plus local.

Il est possible que, par le cumul des rôles, des permissions se trouvent en contradiction pour une capacité donnée. Ceci est résolu par l'application de la règle qui dit que le contexte le plus local l'emporte toujours, sauf si une règle d'interdiction est rencontrée à un niveau supérieur.

Par exemple, Marc est étudiant (rôle) dans un certain cours (contexte), ce qui lui permet d'écrire sur un WiKi. Mais Marc est aussi associé à un rôle Visiteur dans un contexte de module d'activité (pour un certain WiKi) qui l'empêche une écriture (lecture seule) dans ce WiKi. De ce fait, pour ce WiKi particulier, Marc ne pourra effectivement pas écrire quoi que ce soit dans ce WiKi car l'empéchement stipulé dans le contexte très localisé du module d'activité l'emporte.

Si nous définissons une INTERDICTION sur une capacité, cela signifie que cette capacité ne pourra plus être autorisée par un quelconque contexte inférieur. L'interdiction gagne toujours. Par exemple, Jeff est associé à un rôle spécialement constitué pour des étudiants perturbateurs qui interdit toute écriture dans les forums (dans le contexte très général du site), mais dispose d'une ancienne affectation à un rôle de Facilitateur dans le "Forum de Sciences" du cours "Sciences et Mathématiques 101". Comme la règle d'interdiction prévaut, Jeff ne pourra pas écrire dans le forum "Science forum" après sa mise à l'écart.

Autorisation et empêchement s'annulent lorsqu'ils sont applicables à la même capacité dans le même contexte. Si une telle collision survient, c'est la permission du contexte immédiatement supérieur qui est applicable.

Mise à jour à partir d'une version 1.6

Une mise à jour "douce" conduit de la 1.6 à la 1.7. Les rôles existant dans l'ancien modèle (admin, enseignant, étudiant, etc), et les capacités statiques correspondantes sont automatiquement ré-encodées. Ceci est obtenu par la création de rôles prédéfinis (NdT : rôles dits "legacy" - "d'origine" en traduction littérale) au niveau site et cours, puis par la ré-assignation des utilisateurs préexistants à ces nouveaux rôles. Les rôles par défaut ont un jeu de permissions prédéfinies pour un ensemble prédéfini de capacités, afin de produire un statut d'utilisateur conforme à ce qu'il était en 1.6. Sans aucune modification, Moodle réagira exactement de la même façon avant et après la mise à jour.

Administrateurs

Les administrateurs se voient assignés le rôle "legacy" admin (Administrateur) du contexte site.

Créateurs de cours

Les créateurs de cours se voient assignés le rôle "legacy" course creator (Créateur de cours) du contexte site.

Enseignants

Les enseignants se voient assignés le rôle "legacy" teacher (Enseignant) ou le rôle "Enseignant sans édition" dans tous les cours où ils avaient ce rôle.

Étudiants

Les étudiants se voient assignés le rôle "legacy" student (Étudiant) dans tous les cours où ils étaient inscrits.

Visiteurs anonymes

Il existe un seul et unique utilisateur non associé à un rôle du contexte site. Un rôle visiteur anonyme du contexte cours sera attribué à cet utilisateur pour chaque cours qui autorise l'entrée des visiteurs anonymes. Le contrôle de l'accès visiteur anonyme dans un cours passe de trois à seulement deux options (les visiteurs anonymes doivent fournir la clef - accès oui/non). Ce réglage impose la fourniture d'une clef de cours pour les visiteurs anonymes.

Capacités

Vous trouverez ici une liste explicitée des capacités (non encore exhaustive). Il importe que les noms de capacité soient uniques.

Capacités du noyau

Toutes les capacités liées à des fonctionnalités du noyau de Moodle commencent par le préfixe 'moodle/'. Le mot qui suit désigne le type de capacité, et le dernier désigne le nom de la capacité elle-même. Les capacités du noyau de Moodle sont définies dans le fichier lib/db/access.php.

  1. moodle/legacy:guest - Les capacités "legacy" existent pour la transition entre l'ancien schéma de rôles et le nouveau schéma de la version 1.7.
  2. moodle/legacy:student
  3. moodle/legacy:teacher
  4. moodle/legacy:editingteacher
  5. moodle/legacy:coursecreator
  6. moodle/legacy:admin
  7. moodle/site:doanything - une capacité spéciale, pour les administrateurs uniquement, qui surcharge la TOTALITE des autres capacités.
  8. moodle/site:config - applicable dans admin/index.php et config.php (elle sera peut-être subdivisée dans l'avenir) : 1)admin/config.php 2)admin/configure.php 3)blocks/admin/block_admin.php load_content_for_site()
  9. moodle/site:readallmessages - capacité de lire tous les messages et les historiques
  10. moodle/site:approvecourse - capacité d'approuver un cours en attente (demande de cours)
  11. moodle/site:manageblocks - capacité d'ajouter/supprimer/modifier des blocs existants.(contextes site et cours seulement) : 1)_add_edit_controls moodleblock.class.php
  12. moodle/site:backup - capacité de sauvegarder un cours : 1)course/category.php 2)block_admin.php
  13. moodle/site:restore - capacité de restaurer un cours à partir de ce contexte : 1)course/category.php 2)block_admin.php
  14. moodle/site:import - capacité d'importer un cours dans ce contexte : 1)block_admin.php
  15. moodle/site:accessallgroups - capacité d'accéder à tous les groupes, même si l'utilisateur courant n'en fait pas partie.
  16. moodle/site:accessdb - capacité d'accéder directement à la base de données (phpmyadmin).
  17. moodle/site:viewfullnames - capacité de voir les noms complets des autres utilisateurs.
  18. moodle/site:viewparticipants - capacité de voir la liste des participants.
  19. moodle/site:viewreports - capacité de voir les rapports de site/cours.
  20. moodle/site:trustcontent - capacité d'entrer du texte non filtré et de sauter le nettoyage des chaines de caractères dans certains cas.
  21. moodle/site:uploadusers - capacité de charger et mettre à jour des utilisateurs à partir de fichiers texte; moodle/role:assign cette capacité est de plus requise pour pouvoir enregistrer les utilisateurs à des cours.
  22. moodle/blog:view - lire les blogs (dans les contextes site ou cours)
  23. moodle/blog:create - capacité de poster dans les blogs (à un niveau site seulement)
  24. moodle/blog:manageofficialtags - capacité de créer/supprimer des marqueurs officiels que les autres utilisateurs peuvent utiliser dans les blogs (niveau site seulement)
  25. moodle/blog:managepersonaltags - capacité de supprimer de marqueurs personnalisés que les autres utilisateurs pouvaient utiliser (niveau site seulement) Note : les utilisateurs peuvent toujours ajouter des marqueurs personnalisés. Cette capacité ne devrait pas être permise par défaut pour les étudiants.
  26. moodle/blog:manageentries - capacité de modifier/supprimer des entrées de blog (niveau site seulement)
  27. moodle/course:setcurrentsection - capacité à activer la section courante
  28. moodle/course:create - capacité à créer des cours : 1)course/edit.php 2)course/category.php 3)course/index.php
  29. moodle/course:delete - capacité à supprimer des cours : 1)course/category.php
  30. moodle/course:update - capacité à modifier les paramètres d'un cours
  31. moodle/course:view - capacité à voir entre autres les participants
  32. moodle/course:viewparticipants - capacité à voir les participants
  33. moodle/course:viewscales - capacité à consulter les barèmes (dans une popup d'aide ?) : 1)course/scales.php
  34. moodle/course:manageactivities - capacité à ajouter/supprimer/modifier des activités et des ressources (les deux types d'objets sont indissociables)
  35. moodle/course:managescales - capacité à ajouter/supprimer/modifier des barèmes et à les réordonner : 1)blocks/block_admin.php 2)course/scales.php
  36. moodle/course:managegroups - capacité à construire/supprimer/modifier des groupes : 1)course/groups.php 2)course/group.php
  37. moodle/course:managefiles - capacité à gérer l'arbre de fichiers du cours.
  38. moodle/course:managequestions - capacité à gérer la base de questions du cours.
  39. moodle/course:managemetacourse - capacité à gérer les cours ascendants.
  40. moodle/course:reset - capacité à réinitialiser un cours.
  41. moodle/course:useremail - capacité à activer/désactiver son adresse de courrier.
  42. moodle/course:visibility - capacité à montrer/cacher un cours : 1)course/category.php
  43. moodle/course:viewhiddencourses - capacité à voir les cours cachés.
  44. moodle/course:activityvisibility - capacité à montrer/cacher des activités dans un cours.
  45. moodle/course:viewhiddenactivities - capacité à voir les activités cachées d'un cours.
  46. moodle/course:sectionvisibility - capacité à montrer/cacher des sections.
  47. moodle/course:viewhiddensections - capacité à voir des sections cachées.
  48. moodle/course:viewcoursegrades - capacité à voir le carnet de notes d'un cours.
  49. moodle/course:viewhiddenuserfields - capacité à voir tous les champs cachés d'un utilisateur.
  50. moodle/course:managegrades - capacité à noter des items évaluables dans un cours.
  51. moodle/category:create - capacité à créer une catégorie de cours : 1)course/index.php
  52. moodle/category:delete - capacité à supprimer une catégorie de cours : 1)course/index.php
  53. moodle/category:update - capacité à modifier les propriétés des catégories de cours (réordonner et renommer). Actuellement une capacité administrateur : 1)course/category.php
  54. moodle/category:visibility - capacité à montrer/Cacher des catégories de cours : 1)course/index.php
  55. moodle/user:viewusergrades - capacité à voir ses propres notes, ou les notes d'un autre utilisateur (dans le contexte spécifié).
  56. moodle/user:create - capacité à créer un utilisateur : 1) user/edit.php
  57. moodle/user:delete - capacité à supprimer un utilisateur : 1) admin/user.php
  58. moodle/user:readuserblogs - capacité à voir les entrées de blog
  59. moodle/user:update - capacité à modifier les réglages utilisateur : 1) user/edit.php
  60. moodle/user:viewdetails - capacité à voir des données personnelles (par exemple, le nom et le photo).
  61. moodle/user:viewhiddendetails - capacité à voir des propriétés cachées des utilisateurs.
  62. moodle/calendar:manageownentries - capacité à créer/supprimer/modifier des évènements privés.
  63. moodle/calendar:manageentries - créer/supprimer/modifier des évènements.
  64. moodle/role:assign - capacité à assigner des rôles à des utilisateurs.
  65. moodle/role:override - capacité à court-circuiter des rôles (dépend du contexte).
  66. moodle/role:manage - créer/modifier/supprimer des rôles, définir les permissions pour les capacités dans les rôles.
  67. moodle/role:unassignself - capacité à se désassigner de ses propres rôles.
  68. moodle/role:viewhiddenassigns - capacité de voir les attributions de rôles cachées.
  69. moodle/question:import - capacité à importer des questions (contexte de cours).
  70. moodle/question:export - capacité à exporter des questions (contexte de cours)
  71. moodle/question:managecateory - capacité à ajouter/supprimer/modifier des catégories de questions (contexte de cours).
  72. moodle/question:manage - capacité à ajouter/supprimer/modifier des questions (contexte de cours).

Capacités du contexte utilisateur

  1. moodle/user:readuserposts - capacité de lire les posts individuels à partir d'un profil utilisateur (parent?)
  2. moodle/user:readuserblogs - capacité de lire les journaux à partir du profil utilisateur (parent?)
  3. moodle/user:viewuseractivitiesreport - capacité de lire les rapports d'activité à partir du profil utilisateur (parent?)
  4. moodle/user:editprofile - capacité d'édition du profil (seulement et normalement utilisés en contexte site et utilisateur seulement)

Capacités au niveau module

Les capacités au niveau module sont cachées dans une table de la base de données lorsqu'un module est installé ou lorsqu'il est remis à jour. Pour que les définitions de capacités soient mises à jour suite à une modification du module, il suffit d'augmenter le numéro de version du module pour déclencher les fonctions de mise à jour automatiques.

Les conventions de nommage des capacités de contexte module ou bloc conduisent à l'utilisation du schéma 'mod/mod_name:capability'. La partie à gauche du double point est le chemin d'accès au code du module dans l'installation de Moodle. Les capacités d'un module sont définies dans le fichier standard mod/mod_name/db/access.php.

  1. Assignment
    1. mod/assignment:view - capacité de lire la description du devoir
    2. mod/assignment:submit - capacité à poster un devoir
    3. mod/assignment:grade - capacité à noter, et consulter la liste des devoirs rendus
  2. Chat
    1. mod/chat:chat - capacité à rejoindre la discussion
    2. mod/chat:readlog - capacité à consulter les historiques de discussion
    3. mod/chat:deletelog - capacité à effacer les historiques de discussion
  3. Choice
    1. mod/choice:choose - capacité à répondre à un sondage
    2. mod/choice:readresponses - capacité à lire toutes les réponses
    3. mod/choice:deleteresponses - capacité à supprimer toutes les réponses
    4. mod/choice:downloadresponses - capacité à exporter toutes les réponses
  4. Database
    1. mod/data:viewentry - capacité à lire les entrées d'autres utilisateurs
    2. mod/data:writeentry - capacité à lire/modifier/supprimer ses (propres) entrées
    3. mod/data:managetemplates - capacité à ajouter/modifier/supprimer des champs et des modèles
    4. mod/data:manageentries - capacité à modifier/supprimer toutes les entrées
    5. mod/data:comment - capacité à commenter
    6. mod/data:managecomments - capacité à modifier/supprimer tous les commentaires
    7. mod/data:rate - capacité à noter les entrées
    8. mod/data:viewrating - capacité à consulter les évaluations des entrées
    9. mod/data:approve - capacité à approuver une entrée
    10. mod/data:uploadentries - capacité à charger des entrées (massivement)
  5. Exercise
    1. mod/exercise:assess - capacité à exécuter l'exercice
  6. Forum
    1. mod/forum:viewdiscussion
    2. mod/forum:viewdiscussionsfromallgroups
    3. mod/forum:viewhiddentimedposts
    4. mod/forum:startdiscussion
    5. mod/forum:replypost
    6. mod/forum:viewrating
    7. mod/forum:viewanyrating
    8. mod/forum:rate
    9. mod/forum:createattachment
    10. mod/forum:deleteownpost
    11. mod/forum:deleteanypost
    12. mod/forum:splitdiscussions
    13. mod/forum:movediscussions
    14. mod/forum:editanypost
    15. mod/forum:viewqandawithoutposting
    16. mod/forum:viewsubscribers
    17. mod/forum:managesubscriptions
    18. mod/forum:throttlingapplies
  7. Glossary
    1. mod/glossary:write - capacité à ajouter des entrées de glossaire.
    2. mod/glossary:manageentries - capacité à supprimer/modifier des entrées de glossaire.
    3. mod/glossary:managecategories - capacité à ajouter/supprimer/modifier des catégories.
    4. mod/glossary:comment - capacité à commenter une entrée.
    5. mod/glossary:managecomments - capacité à modifier/supprimer des commentaires.
    6. mod/glossary:import - capacité à importer des glossaires.
    7. mod/glossary:export - capacité à exporter un glossaire.
    8. mod/glossary:approve - capacité à approuver des entrées modérées.
    9. mod/glossary:rate - capacité à noter une entrée de glossaire.
    10. mod/glossary:viewrating - capacité à consulter les notes des glossaires.
  8. Hotpot
    1. mod/hotpot:attempt - capacité à répondre à un test HotPotatoes.
    2. mod/hotpot:viewreport - capacité à voir et réviser les rapports.
    3. mod/hotpot:grade - capacité à noter les tests.
    4. mod/hotpot:deleteattempt - capacité à effacer des tentatives.
  9. Label
    1. none
  10. Lams
    1. mod/lams:participate - original student
    2. mod/lams:manage - original teacher
  11. Lesson
    1. mod/lesson:edit - capacité à ajouter et supprimer des pages.
    2. mod/lesson:manage - capacité à consulter les tentatives des étudiants.
  12. Quiz
    1. mod/quiz:grade - capacité à corriger manuellement, surcharger une notation et commenter.
    2. mod/quiz:preview - capacité à prévisualiser le test.
    3. mod/quiz:viewreports - capacité à voir les rapports de tentatives des tests.
    4. mod/quiz:manage - capacité à ajouter/modifier/supprimer (monter/descendre) les questions d'un test.
    5. mod/quiz:attempt - capacité à effectuer le test.
  13. Resource
  14. Scorm
    1. mod/scorm:viewgrades - capacité à voir les évaluations.
  15. Survey
    1. mod/survey:download - downloads survery result
    2. mod/survey:participate - participate/ do survey
    3. mod/survey:readresponses - read all user's responese
  16. Wiki
    1. mod/wiki:participate - original student, meaning depends of type and course setting
    2. mod/wiki:manage - original teacher, manages assigned group; moodle/site:accessallgroups is needed to manage all groups
    3. (Waiting on new wiki)
  17. Workshop
    1. mod/workshop:participate - original student, allows user to submit and assess
    2. mod/workshop:manage - original teacher, user can manage others
    3. (Waiting on new Workshop)

Capacités spéciales d'inscription pédagogique

La convention de nommage pour les capacités d'inscription des utilisateurs à des cours prévoit l'usage du schéma suivant : 'enrol/enrol_name:capability'. Ces capacités sont définies dans le fichier enrol/enrol_name/db/access.php.

  1. Authorize.net Payment Gateway
    1. enrol/authorize:managepayments - gestion des paiement des utilisateurs, capture, annulation, remboursements, suppression etc.

Blocks

  1. activity_modules
    1. None
  2. admin
  3. admin_2
  4. admin_bookmarks
  5. blog_menu
  6. blog_tags
  7. calendar_month
  8. calendar_upcoming
  9. course_list
  10. course_summary
  11. glossary_random
  12. html
  13. loancalc
  14. login
  15. messages
  16. news_items
  17. online_users
  18. participants
  19. quiz_results
  20. recent_activity
  21. rss_client
    1. block/rss_client:createprivatefeeds
    2. block/rss_client:createsharedfeeds
    3. block/rss_client:manageownfeeds
    4. block/rss_client:manageanyfeeds
  22. search
  23. search_forums
  24. section_links
  25. site_main_menu
  26. social_activities


API

Bien que le système de rôles puisse paraître sophistiqué au premier abord, l'utiliser dans des implémentations d'extensions de Moodle est très simple.

  • Une capacité doit être définie une seule fois, et d'une façon qui permette à Moodle de mettre à jour les rôles existants. Vous fournissez cette définition dans un fichier access.php dans le répertoire db de chacun des modules (pour un exemple, voir le fichier mod/forum/db/access.php). Le tableau des capacités affiche des entrées comme ce qui suit (notez les références aux rôles "legacy" qui garantissent une compatibilité descendante):
   'mod/forum:viewforum' => array(
       'captype' => 'read',
       'contextlevel' => CONTEXT_MODULE,
       'legacy' => array(
           'guest' => CAP_PREVENT,
           'student' => CAP_ALLOW,
           'teacher' => CAP_ALLOW,
           'editingteacher' => CAP_ALLOW,
           'coursecreator' => CAP_ALLOW,
           'admin' => CAP_ALLOW
       )
   ),
  • Pour déclencher un chargement et une diffusion de ces capacités dans Moodle, il suffit d'augmenter la version du module. Il n'y a aucun besoin de transférer manuellement des informations car Moodle se charge d'examiner le tableau de capacités et de mettre à jour ses références de rôles.
  • Sur chaque page, vous devrez déterminer dans quel contexte l'utilisateur courant est en train de travailler, par un appel à la fonction get_context_instance(). Par exemple, dans le module forum :
 $context = get_context_instance(CONTEXT_MODULE, $cm->id);
  • Une fois le contexte connu, et à chaque fois que vous voulez déterminer si l'utilisateur a le droit de faire ceci ou celà, vous appelerez la fonction has_capability() comme ceci :
   if (!has_capability('mod/forum:viewforum', $context)) {
       print_error('nopermissiontoviewforum');
   }
  • Si vous voulez juste vérifier l'existence d'un droit qui doit déboucher sur un message d'erreur général en son absence (comme nous l'avons programmé ci-dessus), alors il peut être plus court d'utiliser la fonction require_capability() comme ceci :
   require_capability('mod/forum:viewforum', $context);
  • Notez que des paramètres supplémentaires peuvent être définis pour paramétrer le message d'erreur, en l'absence desquels le message standard "No permissions" est affiché, avec une liste des noms de permissions manquantes.

Pour se conformer au nouveau système de rôles, tous les appels antérieurs à isadmin(), iscoursecreator(), isteacheredit(), isteacher(), isstudent(), et isguest() devront être remplacés par des appels à has_capability() ou require_capability(). Cependant, ces fonctions continueront à exister par souci de compatibilité avec des modules codés "à l'ancienne", mais leur fonctionnement s'appuie désormais sur les rôles "legacy".

Rôles et Métacours

Le comportement des métacours a été légèrement modifié dans Moodle 1.7, en ce sens que s'il ne synchronisait que l'inscription des étudiants entre le métacours et le cours descendant, la synchronisation s'étend désormais à TOUS les rôles. A partir de Moodle 1.8, on peut choisir pour quel rôle la synchronisation doit être faite. Les enseignants et autres utilisateurs conserveront un rôle identique dans le métacours et dans le cours descendant. Techniquement, le métacours synchronise toutes ses attributions de rôle du contexte CONTEXT_COURSE avec son cours descendant ; la seule exception à ce procédé concerne les utilisateurs disposant de la capacité moodle/course:managemetacourse, qui n'ont qu'une synchronisation ascendante : ces utilisateurs ne seront pas désinscrits du métacours s'ils sont enlevés du contexte supérieur ou su le métacours est déconnecté de son cours ascendant.

Pour importer d'autres cours dans un métacours vous devez disposer de la capacité moodle/course:managemetacourse. Vous ne pourrez ajouter manuellement des utilisateurs que si vous disposez de cette capacité moodle/course:managemetacourse, tous les autres participants proviennent de la synchronisation avec le cours descendant - si vous essayez d'inscrire un utilisateur sans disposer de cette capacité, un message d'erreur vous est signifié. Un message d'erreur similaire est présenté si vous essayez de désinscrire un utilisateur d'un métacours alors qu'il reste inscrit dans le cours descendant.

Exemple de situation pour une plate-forme typique :

  • Le gestionnaire d'un méta cours dispose de la capacité moodle/course:managemetacourse dans le contexte site ou cours.
  • Les étudiants sont enregistrés dans divers cours descendants.
  • Les enseignants sont enregistrés dans comme enseignants dans des cours descendants distincts.


Rôles typiques, scénarios et prospectives

Cette section présente un certain nombre de scénarios d'usage des rôles que nous souhaiterions pouvoir prendre en compte. Notez que ces rôles ne sont pas nécessairement tous possibles dans l'implémentation actuelle.

Etudiant

Rôle trivial.

Concepteur de sites

Un rôle pour des personnes responsables de l'apparence du site, mais ne disposant pas de droits d'administration complets ? On pense alors à une possibilité d'éditer des informations relatives aux thèmes en ligne, plutôt que leur modification par accès FTP. Les capacités adéquates seraient

  1. caneditlogos - capacité à changer le(s) logo(s).
  2. caneditcss - capacité à modifier les clauses de style.
  3. candeditlevelatwhichthemeapplies - capacité à modifier les informations relatives à l'application des thèmes.

Conseiller en ingénierie pédagogique

Someone who would want to browse the site and may be asked to comment or contribute to particular discussions or developments in school. Access for this role would be controlled by the school in the case of school level moodles but may be different if there were to be a Local Authority wide Moodle.

Inspecteur pédagogique

Someone who will visit the site to verify the school's self review that comments on home school relationships, extending the classroom etc. They may want to see summaries of usage and reports from surveys garnering parent and pupil views.

Correcteur / Modérateur

A teacher within ths site that has access to assignments and quizzes from another teacher's course for second marking purposes. This may need additional functionality adding to the assignment module so that two sets of grades/feedback can be given to one set of assignments.

Observateur du processus et des pratiques pédagogiques

Many institutions encourage peer observation of teaching, to encourage reflection on practice. In online environments this will be similar to moderation or inspection. The peer observer would need to be able to experience the course "as a student", but also to be able to view summaries of usage, transcripts of interactions (forums/surveys/polls etc), grades assigned (e.g. in assignments).

Examinateur externe

Has all the rights of inspectors, but would also need to be able to review assignments and feedback, view forums, glossaries etc. However, would not want to post, feedback onto the site at all.

Parent

A parent will have one or more children in one or more institutions which could be using one or more moodle instances or a mixture of Learning Platforms. A parent's role will vary depending on the age of their children and whether they are contributing as a parent or a school supporter.

In Early Years (EY=3+4 yr olds) and Key Stage 1 (KS1=5+6 yr olds) they may play/learn on an activity or write for the child. Parents often interpret homework tasks and read to their children perhaps filling in a joint reading diary. In Key Stage 2 (KS2=7-11 yr olds) parents would be more monitoring but may join in as well.

In Key stages 3 (KS3=12-14 yr olds) and 4 (KS4=15+16 yr olds) this changes to more of a monitoring/awareness role where a parent would expect to have a summary report of attendance, attainment and general achievement on a weekly/monthly/termly or annual basis. Parents will often be asked to sign and write back comments about this review report.

In all Key Stages there is a great need for parents to receive communication from the school which they can confirm they have received by signing a form. In some cases this may also involve making choices from a list. It may also involve payment for a trip or disco being returned so there could be the possibility of electronic payments. Also in all Key Satges there may be a home-school agreement which may be signed up to. Could this form part of a site policy system that incorporates a tickable list of activities the parent agrees to the child using (blogs/wikis/forums etc.)?

Parent's evenings often involve complex booking systems that attempt to get parent's and teachers together. Easy for EY/KS1/KS2 very difficult for KS3/KS4. Wow would this help if it was built into the Learning Platform.

In some cases there needs to be confidential communication between the parent and the teacher without the child being party to this. It may involve teaching and learning but could also involve a behaviour or medical issue. Often this may be done via a sealed letter or face to face.

The latest incarnation of OfSTED with the Self Review Framework (SEF) there is a greater emphasis on schools gathering parent voice via surveys and discussion. There is a clear match here with parents have access to parental votes, questionnaires and discussions and for schools to be able to publish news, results and reports back to parents.

In the UK the LP framework and agenda as being pushed by the DfES via Becta emphasises that within the mandatory groups and roles functionality the parent role is likely to be required to meet the LP Framework procurement standard.

Again in the UK, parents have their own independent right of access to a child's educational records. Obviously, children's records must not be made available to other parties, including the parents of other children in the same class. Thus it would be necessary to associate parent accounts with their own child's accounts in such a way that they could, if so desired, have read access to their child's grades, answers and contributions, but generally not those of other children - this may be problematic in the case of wiki activities or forum posts.

There is some concern that children's forum contributions etc may be constrained if their parents are able to read all that they write; this may be particularly problematic in areas such as Personal, Social and Health Education (PSHE), where some schools may choose to use obfuscated usernames.

Gestionnaire

à développer

Coordinateur de séminaire

In a university seminar, typically 8-15 students in their 3rd/4th year, each student is responsible for leading one topic in a study series. I ask each student to research 5-10 resources, then give a powerpoint presentation to the other students. This is followed by an in-class discussion and then online homework. The homework involves some fun quiz questions and then some reflective journal questions. I ask each seminar leader to prepare the quiz questions and journal questions as well as their presentation. To do that, I would like to assign activity-making/authoring roles to the student--either for a short period, or for duration of the whole course. Thus "Allow Quiz Authoring Role" or "Allow Assignment Authoring Role" at the course level or, if possible, even the Topic level (in a topic or week format course) would be important.

Participant non-enseignant à l'élaboration de la stratégie d'évaluation

The gradebook tends to be the domain of the teacher. What if community/peer ratings/marks could also be entered there? What if peer assessment criteria could be designed by the students, not just the teacher?

Visiteur

This would be a role whereby one could allow a visitor to visit one's classroom. This might be a colleague interested in seeing your course, or a journalist who might be writing an article about one's site. They should not be able to see the names of any students anywhere (eg recent activity, forum posts) for privacy reasons. They should be able to try out things like quizzes, and lessons but no grades would be recorded (like in teacher preview mode). They would not be able to participate in choices and forums but could view them. It would be read only in a way like former-student role below but without access to a particular student's records that former student role would grant.

Intervenant invité

This role would be similar to the Visitor role above, but would allow seeing student names, and also allow both reading and posting to a specific forum or forums. We often have "guest speakers" who read and respond to student forum posts. Right now we have to add them as students, which isn't ideal.

Ancien

This role would be of particular use for courses with rolling enrollments. This role would be one where a student had completed all of the requirements of a course (ie assignments, quizzes etc.) but wished to have continued access to the course material for review or consultation. The key factor is that one would give access to the completed student to the notes he read, his work and the teacher's comments on it, but he would not be allowed to do anything that would take up the teacher's time. In other words, a sort-of read-only access to the course. How forums, which might contain pertinent information and would continue to grow, would be handled is a question. Perhaps the student would be shown only what was in the forums at the time he completed the course. He would not be allowed to see any new posts or add any himself. Same thing for database and glossary entries. In other words, a snapshot of the course at the time his regular enrollment ended. He shouldn't be able to see the names or profiles of any newly enrolled students for privacy reasons-hence the restrictions on forum access. One issue that would have to be dealt with would be changes to existing modules-such as resources. Does the student get access to the module as it was or as it is? We have no versioning of resources in Moodle so this would be a problem. What about a teacher changing a quiz question so that the answer is different? What would a former student see?

===Alumnus=== An ALUMNUS should be able to search for all other ALUMNI of the school, interact with them and be enrolled in a seperate course - which is like a META course with all the content of his learning and interaction - as well as capabilities to be a part of this ALUMNI only course. All the teachers of courses during school years should automatically be a part of the ALUMNI course .. which means when an ALUMNUS is enrolled in a course, the original teachers of all his courses get enrolled ? --Anil Sharma 20:54, 15 July 2006 (WST)

Bibliothécaire/Documentaliste

Reference Librarians have an active role in most of the courses taught at some schools such as Earlham College (with Bibliographic Instruction). The Librarian role within Moodle could encompass default read access to all courses (unless prohibited by course teacher) and read access to all components of the course unless access is barred (again by teacher). The Librarians would also perhaps have a block called perhaps Reference Services or Reference Desk with write access where they could deposit resources. Also this block might have a chat applet whereby enrolled students could chat to the Reference Librarian on duty about their bibliographic research needs.

In schools there is often a book review system. This may be covered by the lending system database but may not in which case a librarian may neeed to have a course area they can create a database template to handle the reviews in which case they may have a normal teacher style role? Off topic but course an integration with common schools database systems would be great.

Enseignant

Teachers should have read access to other Teacher's courses unless explictly prohibited. They should be able to set parts of their own course to be totally private (perhaps even to admin?). Just as each activity can currently be set to have group access, each activity could have a permissions field. Teachers could set default permissions for all activities on their course (eg they might disallow Librarian access for example) and then change the access permission for an individual activity.

I think that what is needed is a simple heirarchy of permissions and levels of granularity.

I would take issue with "teachers should have read access to other teacher's courses unless explicitly prohibited." This is a violation of the students' privacy as how they perform and what they do in one class isn't the business of another teacher. Moreover, in the real world a teacher wouldn't suddenly go sit in on a colleague's class without asking permission first. I would not have appreciated such an invasion of privacy as either a teacher or a student. It could be an option, but shouldn't be default.--N Hansen 19:54, 12 June 2006 (WST)

Tuteurs

Teachers may be community adult education trainers making use of a school moodle so must only have access to their courses unless given access elsewhere. They would not necessarily get the default teacher privileges.

Secrétaire/Assistant-étudiant

We often have faculty who want their departmental secretary or student worker to scan and upload files and perhaps create resources. Currently they have to be given teacher access to the course. This is dangerous from a FERPA standpoint since they could easily get access to grades.

Assistant pédagogique

Our Faculty frequently have undergraduate students acting as Teaching Assistants. These students need to be able to add resources, create assignments, and possibly grade assignments. However, due to FERPA they cannot have access to other students' overall grade information. I think the requirements here are slightly different than those of Secretary/Student Worker

Support utilisateur

Help desk agents that have read access for the purposes of trouble shooting. Some care in placing this role within a hierarchy of inheritance is needed, full access will be problematic with FERPA.

Administrateurs et administrateurs délégués

Basically a person in between full Admin and Creator that has the permissions of an Admin but only with respect to courses and students. Currently a Creator has permissions site-wide which does not always meet the requirements of a given organisation (e.g. Department A may not be happy that a person from Department B can create/modify courses within Department A's area). The ability to designate a Creator within a specific category would allow areas to be set up for a faculty/department/organisation and allow the Admin for that area to create/delete courses, upload users, add site-wide entries to the calendar etc.

Rôles dans une procédure multi-rôle

organising the learning process for a group you wish to have the choice to place students in differnt roles: examples of this are:

  • Give a student the role of forum-moderator with edit and chunk-rights
  • Give students different roles & rights in a Webquest design (and change these roles next week
  • Give students different resources, depending of their roles in a rolegame/simulation
  • Give a student the rights to create the section content of next week (and only that week..)

Voir également

Récupérée de « https://docs.moodle.org/19/fr/index.php?title=Développement:Rôles&oldid=9320 »
Powered by MediaWiki