Valery Fremaux

Par rapport à la dernière version téléchargeable.
Revue de code nécessaire.

Workplan :

• • Clef françaises remises à jour
  • Code cleanup (guillemets, requêtes SQL, etc.)
  • Débuggage en cours (en effet, variables mal nommées dans les récupérations de formulaire)
  • Examen des fonctionnalités en cours

Délai de republication : si tout va bien 48 heures.

Je vais être moi-même client du module...  donc... j'my colle.

Ce n'est pas un problème critique :

D'abord la procédure :

revient à la situation d'avant (enlève toutes les tables d'assignement, enfin désinstalle si possible). Au pire, le script SQL suivant fera ce qu'il faut :

DROP TABLE mdl_assignment;
DROP TABLE mdl_assignment_submissions;
DELETE FROM mdl_modules WHERE name = 'assignment'

puis exécute la requête suivante pour éliminer les enregistrements annexes qui gênent (à travers le phpMyAdmin sur la base, onglet 'SQL') :

DELETE FROM

  mdl_log_display

WHERE

   module = 'assignment'

Puis réinstalle.

Il ne serait pas totalement superflu ni idiot de répeter la requête sur la table mdl_log, à moins que l'historique des actions passées ne doivent A TOUT PRIX être conservées pour x ou y raisons :

DELETE FROM

  mdl_log

WHERE

   module = 'assignment'

Maintenant le commentaire.

Moodle devient de plus en plus compliqué à l'intérieur. C'est le prix à payer pour avoir toutes les transformations que tous les utilisateurs, administrateurs et enseignants demandent. Je le dis ici pour faire réfléchir au futur. Moodle est un formidable outil (rarement vu aussi bien fait, et je m'y connais...) souple puissant, mais dont il faudra accepter qu'il s'inscrit dans le pradoxe technique.

Il ne faut surtout pas la recréer. Cette table est obsolète. La définition des étudiants dans Moodle est désormais faite à travers un processus un peu plus compliqué : l'attribution des rôles.

C'est précisément l'essentiel du travail qui est à faire lorsqu'on "rénove" un vieux plugin < 1.7.

Les tables mdl_user_students et mdl_user_teachers ne doivent plusêtre utilisées pour rechercher des étudiants ou des enseignants. On peut encore compter sur get_course_students() et get_course_teachers(), mais cette confiance doit être limitée surtout si des rôles "customisés" sont utilisés.

On doit cependant pouvoir dissocier les utilisateurs ainsi :

enseignant ou utilisateurs "à pouvoir" : disposent dans le contexte courant d'un rôle compatible avec $CFG->coursemanager

etudiants : inverse de l'ensemble précédent et NON isguest()

invités et extérieurs : isguest()

Voici une fonction d'une librairie localisée qui donne un exemple de procédure adéquate pour faire le premier tri :

/**
* get the users that have a cousemanager compatible role
*
* @return an array of teacher records
*/
function planning_get_all_teachers($courseid=0){
    global $CFG;
   
    if ($managerroles = get_config('', 'coursemanager')) {
        $roles = get_records_list('role', 'id', $managerroles);
        $allteachers = array();
        foreach ($roles as $role) {
            if ($courseid){
                $context = get_context_instance(CONTEXT_COURSE, $courseid);
                if ($users = get_role_users($role->id, $context, true, 'id,firstname,lastname', 'u.lastname ASC', true)) {
                    foreach($users as $aUser){
                        $allteachers[$aUser->id] = $aUser->lastname . ' ' . $aUser->firstname;
                    }
                }
            }
            else{
                $userids = get_records('role_assignments', 'roleid', $role->id, '', 'userid,userid');
                if ($userids){
                    $userlist = implode("','", array_keys($userids));
                    $query = "
                       SELECT
                         id,
                         CONCAT(lastname, ' ' , firstname) as fullname
                       FROM
                         {$CFG->prefix}user
                       WHERE
                         id IN ('$userlist')                  
                    ";
                    $users = get_records_sql_menu($query);
                    if ($users) $allteachers = $allteachers + $users;
                }
            }
        }
        return array_unique($allteachers);
    }
    return false;
}

 Cette procédure fonctionnera quelle que soit la politique qui détermine quel(s) rôle(s) a le pouvoir dans un cours par rapport à l'éjout de nouveaux rôles.

Sinon, pour faire plus simple, on peut donc utiliser les fonctions get_course_...

Le problème est pour les requêtes complexes, de type jointure à plusieurs tables que l'on trouve souvent dans les plug-ins avec un appel à get_record(s)_sql(...).

Il faut changer la stratégie d'obtention des données et la décomposer en deux temps :

1. Je vais chercher la liste des enseignants
2. Je réécris la requête sans l'appel à la table mdl_user... avec une bride du type user IN (<liste des ids>) profs.

Voilà. Du taff en perspective... si j'ai bien compris 

Nouvelles du développement :

Lepatch de course est quasiment terminé : il touche deux fichiers course/mod.php, course/lib.php et ajoute un formulaire course/form_change_course.html

Le formulaire existe en deux versions, suivant que ajax est activé ou non :

Sans ajax :

permet de déplacer toute ressource vers un autre cours, au tout début de celui-ci ou comme dernière ressource indexée dans la dernière section.

Avec ajax :

permet de déplacer toute ressource vers n'importe quelle section d'un autre cours, en plaçant cette ressource en queue de section.

Le déplacement fonctionne au jour d'aujourd'hui parfaitement bien sur une étiquette.

Ce W.E. : tests sur les autres activités (avec modèle de données simple/complexe, avec/sans fichiers attachés).

Etude à terminer pour l'upgrade et le déploiement sur une 1.8. Ne touche pas aux tables.