Développement de Moodle

Non, c'est un bug. Je l'avais imputé aux peu de cours que j'avais dans ma plate-forme de développement. Je vais regarder pourquoi je ne trouve pas "mes cours" en tant qu'enseignant.

C'est plutôt un problème de capacités. Le patch exploite deux nouvelles capacités système

moodle/course:exportmodule et moodle/course:importmodule

Je ne sais pour l'instant pas comment les mettre dans le patch. Je vais essayer quelques entrées manuelles dans mdl_capabilities et voir si je peux publier une injection pour ces capacités.

sinon, temporairement dans la nouvelle fonction module_change_course(...) on peut les désactiver dans le code :

        // check capabilities if not admin
        if (!isadmin()){
/*
            $context = get_context_instance(CONTEXT_COURSE, $COURSE->id);
            //require_capability('moodle/course:exportmodule', $context);
            $context = get_context_instance(CONTEXT_COURSE, $courseid);
            require_capability('moodle/course:importmodule', $context);
*/
        }

Il manque des capacités. Voici comment les ajouter simplement :

Dans le fichier /lib/db/access.php vers la ligne §633 :

    'moodle/course:importmodule' => array(

        'riskbitmask' => RISK_SPAM,

        'captype' => 'write',
        'contextlevel' => CONTEXT_COURSE,
        'legacy' => array(
            'editingteacher' => CAP_ALLOW,
            'admin' => CAP_ALLOW
        )
    ),

    'moodle/course:exportmodule' => array(

        'captype' => 'read',
        'contextlevel' => CONTEXT_COURSE,
        'legacy' => array(
            'editingteacher' => CAP_ALLOW,
            'admin' => CAP_ALLOW
        )
    ),
 

Dans le fichier /version.php

Augmenter de 1 unité la version de Moodle.
Aller activer les notification de l'administration (Attention, ça recharge les packs de langues installés administrativement).
Terminer la mise à jour (ne fera pas grand chose qu'inscrire les capacités)

Dans le fichier /lang/en_utf8/role.php §27

$string['course:exportmodule'] = 'Cut out a module';
$string['course:importmodule'] = 'Paste in a module';

Dans le fichier moodledata/lang/fr_utf8/role.php §27

$string['course:exportmodule'] = 'Couper un module d\'un cours';
$string['course:importmodule'] = 'Coller un module dans le cours';

Les capacités sont disponibles et on peut tester le déplacement de ressources par un enseignant éditeur.

Comme j'écrivais tout à l'heure avant que mon post ne se vautre sur une page en python (!??!!!??!!!), seules les ressources dans un répertoire de type :

<moodledata>/<courseid>/moddata/resource/<resourceid>/

seront déplacées. C'est la seule stratégie possible pour savoir ce qui appartient en propriété propre à la ressource/module.

Le problème vient que l'insertion de ressources dans le texte offre un accès générique au répertoire :

<moodledata>/<courseid>

Ce qui est trop haut dans la hiérarchie des fichiers attachés au cours. Je ne vois pas de solution pratique pour connaître les fichiers utilisés "dans le contenu" et en admettant de scanner le contenu des ressources déplacées (ce qui hors stratégie d'un déplacement générique de module), il faudrait savoir celles qui par hazard ne seraient pas réutilisées ailleurs. Un casse-tête absolu.

Pour la deuxième remarque : oui en utilisant un cours tampon on peut arriver à ce simulacre de presse papier. Le patch actuel ne permet le déplacement que d'une ressource à la fois, mais on pourrait imaginer un lien "global" en haut du cours (en mode édition bien sûr) qui permettrait d'accéder au même formulaire de déplacement additionné d'une liste de sélection des modules à déplacer. Traitement couillu en apparence mais ne faisant que plusieurs fois appel à la même fonction de déplacement. Par contre, le "collage" des modules ne peut être fait que massivement (tous les modules groupés) au même endroit d'un cours.

Oui je pense que nous devons aussi traiter le "marketing interne" de nos idées. Je suivrai donc tes conseils.

Simplement, le processus que je prends ici est de d'abord commencer par faire jouer une "taskforce" francophone, et de ne vraiment basculer l'information qu'une fois que le développement ou la fonctionnalité est suffisamment opérationnelle.

L'opération scheduler (non de code "Requin 88" ) a parfaitement réussi grâce à l'aide de Jérome qui nous a permis de proposer une version qui tourne complètement à Kenneth Newquist le mainteneur actuel. Nous ouvrons une collaboration pour fusionner nos idées.

Donc une fois que j'ai stabilisé correctement le patch dans la majorité des cas d'usage, promis je bétonne les forums anglosaxons.