Bonjour à tous,
sur notre plateforme Moodle nous avons créé un cours avec plusieurs activités base de données (une par filière). J'ai voulu définir des responsables pour chaque base de donnée en les déclarant comme enseignant pour une base de donnée précise (celle correspondant à leur filière). Ils voient bien apparaître le bouton activer le mode édition et ils peuvent supprimer la base de donnée. Par contre dans la base de donnée elle-même, ils ont les mêmes possibilités qu'un élève :
_ pas de suppression de fiches;
_ pas de gestion des champs;
_ pas de réglage des modèles...
Le seul moyen que j'ai trouvé pour leur donner ces possibilités, c'est de les nommer administrateur de la base de donnée. Ça marche mais j'aimerais comprendre pourquoi le rôle enseignant ne permet pas cela (alors qu'un enseignant définit au niveau du cours peut faire toutes ces choses).
Merci d'avance.
Bonjour Johann,
Observer : as-tu vérifié les capacités du rôle au niveau système ? Si tu n'en as pas les droits, au niveau du cours ?
Voici les capacités du rôle enseignant sur ma plateforme. Elles sont toutes autorisées, sauf une.
Agir : changer les capacités du rôle enseignant au niveau système, ou accorder des dérogations au niveau du cours, ou au niveau de l'activité. Les permissions du plus bas niveau sont prioritaires par rapport à celle de plus haut niveau.
Observer : as-tu vérifié les capacités du rôle au niveau système ? Si tu n'en as pas les droits, au niveau du cours ?
Voici les capacités du rôle enseignant sur ma plateforme. Elles sont toutes autorisées, sauf une.
Agir : changer les capacités du rôle enseignant au niveau système, ou accorder des dérogations au niveau du cours, ou au niveau de l'activité. Les permissions du plus bas niveau sont prioritaires par rapport à celle de plus haut niveau.
Dans une configuration "de base", donner le rôle "enseignant" à un "étudiant" sur l'activité Base de données permet à cet utilisateur de faire les actions que tu décris, suppression des fiches, modification des modèles ...
Si sur ton installation, ce n'est pas le cas, c'est que des modifications des rôles classiques ont été effectuées avec des incompatibilités.
Pour compléter la réponse de Fred, il faut également vérifier les capacités du rôle "étudiant" afin de vérifier que certaines actions n'ont pas été redéfinies à "empêcher" ou "interdire", ce qui aurait priorité sur la réécriture des capacités du rôle "enseignant" qui sont "héritées" du rôle inférieur.
En image jointe les capacités originelles du rôle étudiant pour les bases de données.
Si sur ton installation, ce n'est pas le cas, c'est que des modifications des rôles classiques ont été effectuées avec des incompatibilités.
Pour compléter la réponse de Fred, il faut également vérifier les capacités du rôle "étudiant" afin de vérifier que certaines actions n'ont pas été redéfinies à "empêcher" ou "interdire", ce qui aurait priorité sur la réécriture des capacités du rôle "enseignant" qui sont "héritées" du rôle inférieur.
En image jointe les capacités originelles du rôle étudiant pour les bases de données.
Salut Jérôme,
ton interprétation implique une autre lecture de la requête de Johann, si je comprends bien : Johann souhaiterait attribuer à des étudiants des capacités d'édition et de création sur la base, et non point à des enseignants ? A certains ou à tous ?
Auquel cas, (à certains) créer un rôle d'étudiant éditeur de base de données au niveau système ? ou (à tous) déroger au rôle étudiant au niveau du cours ou sur chaque base de données ?
ton interprétation implique une autre lecture de la requête de Johann, si je comprends bien : Johann souhaiterait attribuer à des étudiants des capacités d'édition et de création sur la base, et non point à des enseignants ? A certains ou à tous ?
Auquel cas, (à certains) créer un rôle d'étudiant éditeur de base de données au niveau système ? ou (à tous) déroger au rôle étudiant au niveau du cours ou sur chaque base de données ?
Ce que je comprends:
C'est valable dans le contexte système, du cours ET/OU dans celui réduit à l'activité "base de données".
Il faut donc:
- Johann souhaiterait que CERTAINS étudiants d'un cours se voient confier la gestion d'une base de données spécifique parmi d'autres dans ce cours uniquement.
C'est valable dans le contexte système, du cours ET/OU dans celui réduit à l'activité "base de données".
Il faut donc:
- soit créer un nouveau rôle ne gérant que les capacités voulues sur la base de données et ne l'attribuer que pour l'activité visée, (mais c'est lourd et ça ne sert à rien)
- où plus simplement attribuer le rôle "enseignant" à l'étudiant responsable QUE dans le contexte de la base de données dont il sera le responsable. Il ne pourra alors intervenir dans les autres bases (ou les autres activités) de ce cours ou de n'importe quel autre cours de la plateforme.
L'interprétation de ma requête par Jérôme Demiaux est la bonne, et ce qui m'inquiète c'est que la 2ème possibilité qu'il décrit (donner le rôle enseignant à un étudiant dans le contexte de la base de donnée) est bien l'opération que j'ai réalisée. Je vais vérifier les rôles pour voir s'il y a des incompatibilités.
Ça y est j'ai trouvé grâce à vous. C'était en effet un problème de droit dans un autre contexte pour les étudiants : au niveau du cours . durant une période de test nous avions interdit aux étudiants de supprimer leurs propres fiches ainsi que d'autres choses. En rétablissant ces droits aux étudiants et en nommant l'un d'entre eux enseignant dans le contexte base de donnée, tout fonctionne parfaitement.
Je n'avais pas compris ce concept d'héritage des rôles inférieurs, je vais essayer de revoir ça.
Dans tous les cas, merci beaucoup pour votre aide précieuse.
Je n'avais pas compris ce concept d'héritage des rôles inférieurs, je vais essayer de revoir ça.
Dans tous les cas, merci beaucoup pour votre aide précieuse.
Je me suis mal exprimé.
Le terme héritage ne convient pas, il faudrait mieux parler de superposition de rôles où les différentes capacités possèdent un ordre de priorité.
Le terme héritage ne convient pas, il faudrait mieux parler de superposition de rôles où les différentes capacités possèdent un ordre de priorité.
Merci pour la précision, je vais tout de même essayer de revoir cette histoire parce que cette notion m'avait complètement échappé. Tu aurais un passage qui correspond dans la documentation ?
Merci d'avance.
Merci d'avance.
Le problème que tu as rencontré est assez fréquent.
Je me suis souvent fait piéger sur ce point.
Depuis, sur la base des conseils de Nicolas (Moodlemoot de Nantes) je sais que :
Daniel
PS: La pyramide est un cadeau à Jérôme
Je me suis souvent fait piéger sur ce point.
Depuis, sur la base des conseils de Nicolas (Moodlemoot de Nantes) je sais que :
- En général il est conseillé d'attribuer les rôles au plus près du besoin compte-tenu qu'un rôle de niveau supérieur l'emporte sur un rôle de niveau inférieur et qu'en plus un rôle attribué en haut de la pyramide Moodle l'emporte sur un rôle situé à la base.
- De plus il vaut mieux aussi créer de nouveaux rôles que modifier les droits de rôles existants.
Daniel
PS: La pyramide est un cadeau à Jérôme
Bonjour Daniel,
je pensais que la gestion des capacités fonctionnait dans l'autre sens que celui que tu décris. D'après ce que j'avais compris, une permission définie au plus bas de la pyramide (i.e. au niveau des activités) était prioritaire sur les contextes supérieurs (du plus bas au plus haut : cours, catégorie, système).
Ai-je mal compris la doc ou ton message ?
Frédéric
je pensais que la gestion des capacités fonctionnait dans l'autre sens que celui que tu décris. D'après ce que j'avais compris, une permission définie au plus bas de la pyramide (i.e. au niveau des activités) était prioritaire sur les contextes supérieurs (du plus bas au plus haut : cours, catégorie, système).
Ai-je mal compris la doc ou ton message ?
Frédéric
Il n'y a pas de hiérarchie proprement dite dans la gestion des capacités.
Une capacité possède quatre états distincts (hériter, autoriser, empêcher et interdire).
Le calcul du résultat de la combinaison de ces états bien expliqué dans cette page de la documentation permet de trouver lequel en sortira vainqueur.
Sans trop se prendre la tête, la simple analyse logique des capacités attribuées à l'instant T nous donne généralement la bonne réponse. Ainsi si dans n'importe quel contexte, la capacité se trouve dans un rôle à "Interdire", alors cette capacité ne sera pas attribué à ce participant, quels que soient ses autres rôles ....
Une capacité possède quatre états distincts (hériter, autoriser, empêcher et interdire).
Le calcul du résultat de la combinaison de ces états bien expliqué dans cette page de la documentation permet de trouver lequel en sortira vainqueur.
Sans trop se prendre la tête, la simple analyse logique des capacités attribuées à l'instant T nous donne généralement la bonne réponse. Ainsi si dans n'importe quel contexte, la capacité se trouve dans un rôle à "Interdire", alors cette capacité ne sera pas attribué à ce participant, quels que soient ses autres rôles ....
Précision : Dans mon message précédent je parlais des rôles et non des capacités.
Il est assez rare que j'intervienne au niveau des capacités.
Il est assez rare que j'intervienne au niveau des capacités.