Terrain 11 — Rôles & permissions

Les rôles standards : Gestionnaire, Créateur de cours, Enseignant (editingteacher), Enseignant non-éditeur (teacher), Étudiant, Invité, Utilisateur authentifié. Chacun est éditable (avec prudence). L’archétype de départ.

Une capability suit type/composant:action : mod/assign:grade (noter un devoir), moodle/course:manageactivities, block/html:addinstance. Le préfixe = le composant (frankenstyle) qui la déclare. Tes plugins en déclareront (terrain 13).

Non défini (hérite) · Autoriser (accorde) · Empêcher (retire, mais surchargeable plus bas) · Interdire (retire définitivement, non surchargeable). Comprendre Empêcher vs Interdire est le point subtil des permissions Moodle.

Définir les rôles → Ajouter un rôle → « Utiliser un rôle existant comme base » (duplication). On repart d’un jeu de capabilities proche puis on ajuste. Bien plus sûr que de partir de zéro. Ne jamais modifier les rôles standards pour un besoin ponctuel.

On coche mod/assign:grade = Autoriser, et moodle/course:manageactivities = Empêcher. Résultat : un rôle qui note sans éditer. C’est le moindre privilège : donner exactement ce qu’il faut, pas plus.

Un rôle déclare les contextes où il est attribuable : Système, Catégorie, Cours, Module d’activité, Bloc, Utilisateur. Un rôle « Étudiant » s’attribue au cours ; un « Gestionnaire » aux catégories/système. La portée est bornée dès la définition.

Système
 └─ Catégorie
     └─ Cours
         └─ Module d'activité (et Blocs, Utilisateurs)

Un rôle/permission attribué haut est hérité en bas. Un enseignant sur une catégorie l’est dans tous ses cours. Comprendre cet arbre = comprendre toute la sécurité Moodle (et coder juste, terrain 16).

Cours → Participants (ou « Attribuer les rôles » du contexte) → ajoute l’utilisateur avec le rôle. Le rôle vaut ici et en dessous. Le même utilisateur peut avoir un rôle différent ailleurs (terrain 02, jeu 11).

Une surcharge (override) change une capability pour un rôle dans ce contexte seulement, sans modifier la définition globale du rôle. C’est la bonne façon d’adapter localement (ex. forum en lecture seule dans un cours). Chirurgical et réversible.

Contexte → Permissions → Vérifier les permissions : choisis un utilisateur → Moodle liste ce qu’il peut/ne peut pas, capability par capability, en résolvant tout l’héritage. L’outil de diagnostic n°1 des droits. Indispensable pour déboguer un accès.

Empêcher en haut peut être ré-autorisé plus bas (le cours gagne). Interdire en haut gagne toujours, quel que soit le réglage plus bas. Règle d’or : Interdire > Empêcher/Autoriser. Réserve « Interdire » aux cas vraiment définitifs.

Un bloc déclare addinstance (ajouter dans un cours) et myaddinstance (ajouter au tableau de bord). Ces capabilities décident qui peut poser le bloc. Tu en déclareras dans ton bloc (terrain 14). Les blocs ont leur propre contexte.

Chaque capability porte des flags de risque (RISK_XSS, RISK_CONFIG, RISK_PERSONAL, RISK_SPAM, RISK_DATALOSS). Ils signalent qu’accorder ce droit ouvre une surface. À considérer avant d’élargir un rôle. Tes plugins déclarent ces risques dans db/access.php (terrain 13).

Tout compte connecté a le rôle Utilisateur authentifié (au contexte système) en plus de ses rôles de cours. Modifier ce rôle affecte tout le monde : à toucher avec une extrême prudence. Idem « Invité ».

Rôle avec moodle/course:create (et le minimum associé), attribuable au contexte catégorie, attribué à un référent. Il crée des cours dans son département sans autres pouvoirs. Cas typique de délégation par le moindre privilège.

Les définitions de rôles/capabilities sont cachées. Après un changement (surtout via code/plugin), purge les caches (terrain 10) pour voir l’effet réel. Sinon tu débogues un état périmé. Idem après un nouveau db/access.php (terrain 13).

« Vérifier les permissions » (jeu 10) donne la théorie ; « Se connecter en tant que » (terrain 02) donne le ressenti réel (menus, boutons présents/absents). Les deux ensemble valident un rôle sans surprise.

Cacher un lien ne protège rien : une URL forcée contourne l’UI. Le contrôle serveur has_capability($cap, $context) (ou require_capability) est obligatoire dans chaque page/action de plugin (terrain 16). Le système de permissions n’a de valeur que si le code l’interroge.

Passer en revue les capabilities (surtout à risque) d’un rôle révèle les élargissements dangereux (souvent hérités d’un plugin). Auditer périodiquement, retirer le superflu = moindre privilège appliqué. Surtout après l’ajout de plugins qui créent des rôles.

Tu maîtrises le modèle rôles × capabilities × contextes — le plus puissant des LMS et le socle de la sécurité. C’est exactement ce que tes plugins devront respecter (db/access.php + has_capability()). Fin du bloc découverte/admin (terrains 01–11). Cap sur le code : environnement de dev (terrain 12).