Valery Fremaux

Avec quelques Moodlers, nous démarrons une activité autour de Moodle. Une société existe qui pourrait répondre à un appel d'offre, appuyée par d'autres contacts plus "solides" institutionnellement.

L'une des difficultés à faire passer cette idée est que Moodle est singulièrement absent de tous les dossiers en cours d'ENT (Espace Numériques de Travail) déposés au Ministère de l'Education et dans la lignée des appels d'offres nationaux autour du programme Campus Numérique (phase 2).

La philosophie Moodle se heurte d'ailleurs de plein fouet avec l'approche du Ministère à ce sujet (approche pilotée par les usages (down-top) vs. approche pilotée par la hiérarchie (top-donw)).

Si l'AFPA est un organisme suffisamment indépendant pour évaluer ses opportunités à part des recommandations institutionnelles, il y a peut-être une chance.

Attention aux mirages du "serveur virtuel". J'ai expérimenté ce type d'hébergement chez Amen (Virtuozzo) avec des performances déplorables, bien pires que l'hébergement mutualisé chez le même hébergeur.

Le serveur virtuel ne permet "que" d'accéder un peu plus profond dans le choix des versions de logiciels à installer et la configuration système (puisqu'on voit son système comme si on avait une machine à soi). Mais dans la pratique des hébergeurs, le hardware est mutualisé, et doit supporter le "supersystème" qui virtualise les systèmes d'exploitation. Bilan, la machine rame tant qu'elle en peut plus si le hard est trop partagé.   

Il existe bien un moyen mais qui est aujourd"hui un peu lourd à mettre en oeuvre de façon systématique :

avec le module opencourseware (patch publié en tierce-partie), il est possible de prendre le contrôle individuel de la publication de chaque resource ou activité dans un cours globalement accessible au public (invité). Ceci permet de cacher très localement certaines ressources qui ne doivent pas apparaître au public (pour cause de copyright ou de droits limités par exemple). La technique marche bien (http://sifoci.eisti.fr l'utilise mais encore expérimentalement).

Le seul ennui de cette technique est que précisément, comme le contrôle est "local" il faut fermer explicitement les ressources à cacher, ce qui peut demander un travail important sur une grande masse de documents.

D'autres techniques demanderont probablement à modifier le code de Moodle pour rediriger les "bots" connus vers des pages virtuelles ne diffusant que des informations choisies (par exemple, le résumé de cours, comme tu le suggères).

La procédure par les bases est la suivante :

repérer le compte dans la table mdl_user (bon login, bon nom etc). Mémoriser la valeur de l'id.

Visualiser la table mdl_role_assignements (qui attribue les rôles aux utilisateurs, le rôle administrateur vaut 1)

Si il existe un enregistrement pour (roleid = 1, contextid = 1, userid = <la valeur précédente>) tout va bien, sinon le créer :

INSERT INTO
   mdl_role_assignements(
   roleid,
   contextid,
   userid,
   hidden,
   timestart,
   timeend,
   timemodified,
   modifierid,
   enrol,
   sortorder
)
VALUES( 1,
        1,
        <la valeur precedente>,
        0,
        0,
        0,
        NOW(),
        0,
        'manual',
        0 )

Il faut aussi peut-être désactiver le cache Moodle à partir de 1.7. S'il est activé, la production de certaines ressources publiées peut s'y trouver.

Administration->Serveur->Performances->cache