Suite à la discussion : http://moodle.org/mod/forum/discuss.php?d=83067
Depuis la version 1.7, Moodle à ajouté le système de roles et de capacités qui permet de définir des possibilités d'action non pas en partant de la définition des utilisateurs, mais au contraire par définition de capacités "désincarnées" dans les applications elles-mêmes.
C'est à partir de cet ensemble de capacités qu'un utilisateur, si les capacités sont attribuées à son rôle. La page de documentation sur les rôles et capacités est ici.
Une fois cette page lue, vous pouvez envisager une stratégie pour définir les capacités de votre module (ou bloc).
Première étape : identifier les "cas d'usage" qui sont soumis à des restrictions d'usage par les acteurs
Ceci ne peut se faire que dans la connaissance de votre propre modèle applicatif. Vous devez vous en faire une idée sous la forme :
L'étudiant peut faire cela, l'enseignant peut faire cela => une personne X disposant de la capacité de "faire cela" pourra faire cela.
Si chacun de vos "cas d'usage" restreint est confronté aux cinq roles de base de Moodle, vous pouvez alors spécifier les valeurs par défaut, comme le préconise la doc.
Deuxième étape : nommer ces capacités
Chacune de ces capacités doit ensuite être nommée selon un schéma :
mod/<nommodule>:<nomcapacité>
ou
block/<nomblock>:<nomcapacité>
<nomcapacité> s'exprime comme un "candothis" ou "candothat", ou des verbes impératif :
:canseehiddenthings
:canedit
:canchangethis
Sont des noms de capacités pertinents
:thisisviewable
:thisvisibility
Sont des noms non pertinents d'un point de vue strictement grammatical. (capacité d'un objet de l'application et non d'un acteur pour le premier, définition d'une propriété statique pour l'autre).
Troisème étape : créer le fichier de capacités : db/access.php
Ce fichier contient le préréglage des capacités pour les rôles standard de Moodle (admin, editingteacher, teacher, student, guest).
Il s'agit d'un tableau de descriptions de la forme :
'mod/<modname>:<capacityname>' => array(
'captype' => 'read',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
)
captype est 'read' or 'write', suivant le type d'action sur les données qu'entraine l'usage de la capacité.
contextlevel vaut en général :
Pour les modules : CONTEXT_MODULE
Pour les blocs : CONTEXT_BLOCK
Mais le fichier access laisse libre de décrire des capacités dans d'autres niveaux de contexte, par exemple, pour un bloc qui n'aurait de pertinence que sur la face avant, on pourrait penser définir des capacités de type CONTEXT_SYSTEM, mais le cas est plutôt rare.
Le tableau "legacy" permet de fixer une valeur par défaut de la capacité pour le rôle standard choisi. En principe, on ne règle pas les capacités d'admin, celui-ci ayant "tous les droits" par définition. Il serait donc singulier d'interdire à l'admin des choses autorisées à des simples utilisateurs, mais on peut imaginer des cas très particuliers de données "confidentielles utilisateur". Ceci pose simplement un problème de responsabilité : le propriétaire du site pourrait être tenu comme responsable des données diffusées à partir de ce type de données protégées. La dernière jurisprudence WikiPedia semblerait démontrer plutôt le contraire.
Quatrième étape : invoquer les capacités dans le code
Au moment d'écrire le code applicatif, on doit invoquer la capacité "courante" de l'utilisateur "courant" dans le contexte approprié.
Ceci s'exécute par deux mises en oeuvres : la première est d'obtenir un contexte adéquat :
$context = get_context_instance(<context_level>, <cm_id>);
par exemple :
$context = get_context_instance(CONTEXT_MODULE, $mychatmoduleid);
Attention, il s'agit de l'id du module de cours et non de l'id de l'instance de l'activité (en général, disponible par $cm->id si vous avez recopié de début "standard" ducode d'un module.
Il existe d'autres façons d'obtenir un contexte.
Vous récupérez le plus souvent un contexte du même niveau que le code environnant :
Dans un module : CONTEXT_MODULE
Dans un bloc : CONTEXT_BLOCK
Certaines vérifications toutefois, peuvent demander la vérification de capacités n'appartenant pas au jeu de capacité de votre module. La liste est fournie dans la documentation développeur, ici.
Même s'il s'agit de capacités de plus haut niveau, il est d'usage de toujours les évaluer dans le contexte courant (règles ci-dessus). Le mécanisme de résolution de rôle et de surcharge vous assurant une valeur en général "consistente".
La vérification s'effectue dans la grande majorité des cas par l'écriture :
if (has_capability('<capname>', $context); // (j'ai mis n'importe quoi).
Exemple:
if (has_capability('mod/chat:canviewnotownerdiscussions', $context); // (j'ai mis n'importe quoi).
Cinquième partie : cas spéciaux
Un problème peut se poser pour les filtres. Comment choisir le bon niveau de capacité. Le problème majeur vient du fait qu'en principe le filtre de base ne connait pas le contexte.
En fait, un filtre peut toujours faire appel à la variable globale $COURSE pour savoir si le traitement s'effectue dans le cadre d'un cours ou est en première page. On peut alors invoquer des niveaux de contexte CONTEXT_COURSE.
La situation est plus difficile pour savoir, dans un filtre, que l'on est dans le traitement d'un module particulier. On essaie d'éviter d'avoir besoin de cette information dans un filtre.
Un autre cas particulier est le développement d'un "bloc prétexte". J'appelle un "bloc prétexte" un bloc dont le seul rôle est d'acheminer l'utilisateur vers une sous-application globale, indépendante des cours. (par exemple, le moteur de recherche global est une sous-application de ce type). Là encore il faudra réfléchir plus profondément sur le bon usage des niveaux de contexte et les moyens de faire passer l'information adéquate.