bonjour
je voulais de creer un nouveau role lors de l'installation de mon module qui a peu pres le meme capability de editingteacher avec un peu des différences
ma question est ce que j'ai peux cloner le role de editing teacher ou c'est pas possible dans moodle
$monrole=clone($roleeditingteacher)?
ou il ya d'autres methode à faire?
merci en avance
bonjour
pas besoin de jouer dans les fichiers php de moodle pour cloner un rôle existant (sauf si je n'ai pas compris le contexte exact de la demande)
depuis moodle :
Administration du site /
► Utilisateurs /
► Permissions /
► Définition des rôles
à côté du rôle editingteacher dans la colonne nom abrégé, il y a une icône présentant 2 pages collées, c'est le clonage.
c'est tout.
bonjour
oui je sais ca ,mais mon but est de créer ce role lors de l'installation de mon module au lieu d'engager quelqu"un de faire ca ?
est ce possible ?
Peut-être ceci : https://moodle.org/mod/forum/discuss.php?d=139641
Mais cela me semble une mauvaise idée : si chaque module définit ses propres rôles, cela deviendra vite un cauchemar pour les pauvres administrateurs. Peut-être serait-il plus judicieux de vérifier que l'utilisateur dispose des "bonnes" capacités.
Et : est-ce que l'investissement nécessaire à programmer cela dans le module vaut vraiment la peine, alors que créer un rôle dans l'interface est si rapide et simple ?
function xmldb_block_publishflow_install(){
global $USER, $DB, $CFG;
// We need add a custom role here : disabledstudent
// A disabled student still is enrolled within a course, but cannot interfere anymore with content
if ($newroleid = create_role(get_string('disabledstudentrole', 'block_publishflow'), 'disabledstudent', get_string('disabledstudentdesc', 'block_publishflow'))){
$standardwritecapsforstudents = array("moodle/calendar:manageownentries",
"moodle/calendar:managegroupentries",
"moodle/calendar:manageentries",
"mod/assignment:submit",
"mod/chat:chat",
"mod/chat:deletelog",
"mod/choice:choose",
"mod/choice:deleteresponses",
"mod/data:writeentry",
"mod/data:comment",
"mod/data:rate",
"mod/data:approve",
"mod/data:manageentries",
"mod/data:managecomments",
"mod/data:managetemplates",
"mod/data:manageuserpresets",
"mod/forum:startdiscussion",
"mod/forum:replypost",
"mod/forum:addnews",
"mod/forum:replynews",
"mod/forum:rate",
"mod/forum:createattachment",
"mod/forum:editanypost",
"mod/forum:throttlingapplies",
"mod/glossary:write",
"mod/glossary:manageentries",
"mod/glossary:managecategories",
"mod/glossary:comment",
"mod/glossary:managecomments",
"mod/glossary:import",
"mod/glossary:approve",
"mod/glossary:rate",
"mod/lams:participate",
"mod/lams:manage",
"mod/lesson:edit",
"mod/lesson:manage",
"mod/quiz:attempt",
"mod/quiz:manage",
"mod/quiz:preview",
"mod/quiz:grade",
"mod/quiz:deleteattempts",
"mod/scorm:skipview",
"mod/scorm:savetrack",
"mod/wiki:participate",
"mod/wiki:manage",
"mod/wiki:overridelock",
"mod/workshop:participate",
"mod/workshop:manage",
"block/rss_client:createprivatefeeds",
"block/rss_client:createsharedfeeds",
"block/rss_client:manageownfeeds",
"block/rss_client:manageanyfeeds");
foreach($standardwritecapsforstudents as $writecap){
$rolecap = new StdClass;
$rolecap->roleid = $newroleid;
$rolecap->context = 1;
$rolecap->capability = $writecap;
$rolecap->timemodified = time();
$rolecap->permission = CAP_PREVENT;
$rolecap->modifierid = $USER->id;
$DB->insert_record('role_capabilities', $rolecap);
}
}
Bonjour,
Je m'associe à mes petits camarades pour désapprouver l'insertion d'une création automatique d'un rôle au chargement d'un nouveau module.
Si de nouvelles capacités sont créées (cela doit forcément être le cas avec au moins le "addinstance"), il vous faut simplement faire en sorte qu'elles soient correctement implantées dans les rôles livrés en standard et fournir une documentation explicite sur les fonctionnalités de ces nouvelles capacités.
Si par la suite les gestionnaires d'une plateforme désirent modifier le fonctionnement de tel ou tel rôle, cela doit rester leur choix et non pas être imposé par le créateur de l'activité.
Qu’adviendrait-il si l'installation de chaque extension parmi le millier disponible créait un rôle spécifique ?
Jérôme.
Oui et non,
encore une fois il n'y pas de réponse dogmatique.
L'acceptabilité d'un plugin est aussi sa facilité d'emploi et de mise en oeuvre, et un plugin nécessitant trois kilomètres de prérequis pour avoir le fonctionnement attendu n'est pas très accrocheur.
Il est cependant en effet déconseillé de créer des nouveaux rôles SI POSSIBLE, c'est-à-dire si la "fonction" qui est induite par l'usage de ce plugin se raccroche a peu de choses près à un rôle existant.
Par contre si la fonction est totalement nouvelle, il est en effet plus commode de proposer un rôle adapté à son plugin, lorsqu'il n'interfère avec aucune des autres fonctions de Moodle :
Exemple :
Le système de ressources centrales mutualisées induit la notion de Documentaliste (celui qui édite l'indexation de la librairie et la gère). Cette notion ne se rapproche d'aucun autre role car ces personnes ne sont ni étudiantes, ni enseignantes, ni creatrices de cours ni autre chose, et qu'une bonne partie du dispositif (la librairie) se situe hors cours (contexte système). Nous avons suivi l'idée de ne pas créer de rôles supplémentaires et donner par des capacités un rôle "effectif" dans les composants de cet ensemble. Le résultat reste que c'est pas clair en termes de gestion. A la question : Qui sont mes documentalistes nommés ? il faut que je réponde très indirectement par une analyse des capacités...
Exemple 2 :
Nous introduisons une notion de "Propriétaire de cours" pour une plateforme "opencourseware" d'accueil de cours en ligne. De rôle similaire à l'enseignant auteur, nous avons besoin des deux (et uniquement si ce composant est installé) différenciés (tous les enseignants nommés ne sont pas propriétaires).
Dans tous les cas :
Tout ce qui est installé par un composant doit être proprement démonté par ce composant et être parfaitement réversible.
install.php => uninstall.php
Creation du role => Suppression du rôle et nettoyage de toutes les assignations
Ajout de capacités => Suppression de la capacité et de toutes les surcharges de capacité.
Il reste un point en faveur de mes collègues : Le problème induit par les backups et le transport de données utilisateur entre moodles.... mais ce problème reste entier avec des rôles créés à la main.
