Valery Fremaux

Plus les remarques sont nombreuses, plus elles permettent d'approcher une solution "utilisable" au sens des "utilisateurs".

1. Message de debug activés : un echo malencontreux enlevé depuis §286 scheduler/lib.php enlever le echo $select; s'il y est.

2. Mettre à 1 : fait mais un bête s de trop dans une variable.

§485 scheduler/view.php doit afficher :

            $exclusivity = $slot->exclusivity;

3. Message parasite : j'arrive pas à le reproduire. Je ne vois même pas ce qui pourrait le provoquer à cet endroit là. Je scanne les sources quand même....

et non :

            $exclusivisty = $slot->exclusivity;

Fixes :

• / fixé
• code ".. checked>" fixé
• bouton "Continuer" recodé et relabelisé
• Structure réagencée les vues étudiant et enseignant sont dans des fichiers séparés.
• Vérification de créneaux imbriqués l'un dans l'autre : requête fixée.
• Autorisation de pouvoir prendre un rendez-vous pour un autre prof :
  • capacité mod/scheduler:canscheduletootherteachers ajoutée
  • la capacité est acquise par défaut pour les admin et les "responsables de cours".
• Bouton "enregistrer, puis ajouter un autre étudiant à ce créneau" : non pertinent, supprimé
• Réglage par défaut de la limite à 1 pour le formulaire
• Bouton "un créneau" : fixé 
• Autres erreurs de navigation non mentionnées : fixées
• Noms d'enseignants dans les statistiques enseignant (?? non reproduit)
• Clefs manquantes :
  • limited : fixée
  • planified : non trouvée
• Abandon de planification : non réglé
  

Ok, je regarde tout ça.

Je dois composer pour certaines remarques avec un modèle de données d'origine qui n'est pas toujours très bien conçu (d'un point de vue de l'analyse strictement Merisienne). Aller plus loin dans le redesign reviendrait quasiment à produire un autre module. Je suis un peu réticent à aller jusque là, car il faudra bien le soumettre aux "dépositaires originaux" à un moment où un autre.

On va régler les points "bloquants" d'abord (contraintes non détectées) et les petits détails. (slash, code apparent, clefs, sémantiques de boutons, etc.).

Le principe du remplacement des créneaux non compatibles est lié à cette structure du modèle de données qui est dénormalisé. Je ne sais pas si je pourrai faire mieux (du moins, sans un recours à Ajax, que je maîtrise de mieux en mieux, mais dont l'usage reste pour l'instant expérimental au niveau des distribs, dixit Martin). L'essentiel est que nous atteignons rapidement une version opératoire pour tous de ce module bien pratique. 

La proposition de fonctionnalité est faite dans le tracker :

http://tracker.moodle.org/browse/MDL-11625

La solution est apportée sous forme d'un patch (ci-joint). Ce patch :

• touche à course/lib.php en ajoutant deux fonctions à la fin et en modifiant la fonction "make_editing_buttons()" pour ajouter l'icone de transfert.
• touche à course/mod.php en ajoutant un cas de réponse d'action, et en ajoutant l'entrée pour l'affichage du formulaire de confirmation/paramétrage
• ajoute un formulaire mod_change_course.html (confirmation paramétrage du transfert).
• ajoute un Web Service Ajax pour ce formulaire
• nécessite l'ajout de la librairie additionnelle lib/filesystemlib.php permettant la manipulation du container moodledata à haut niveau d'abstraction (fournie).

La solution ajoute une icone à la liste des boutons d'édition qui déclenche la procédure de déplacement de l'activité.

Le formulaire de confirmation permet de prendre quelques décisions sur la destination de l'activité :

• Le cours destinataire (doit être un cours où l'utilisateur est enseignant éditeur ou équivalent)
• Si Ajax est activé :
  • La section à la fin de laquelle l'activité/ressource déplacée doit apparaître.
• Sinon :
  • un choix simple (au début du cours ou à la fin de la dernière section du cours)
• La visibilité de l'activité/ressource dans le cours d'arrivée.
• L'activation (par défaut) du transport des ressources "standard" associées au module (ces ressources DOIVENT se situer dans un répertoire précis, formé ainsi :

 [%%moodledata%%]/<courseid>/moddata/<modname>/<modid> 

Tous autre fichier utilisé dans le module hors de ce répertoire ne sera pas déplacé.

Pour la phase d'évaluation et de stabilisation du procédé, il est possible de demander un rapport complet sur l'exécution du déplacement.

La ressource ou module d'activité ne change pas d'identité. C'est l'inscription du module dans le cours qui est entièrement mise à jour pour refléter le déplacement.

La procédure a été testée pour :

• les ressources
• les liens vers le web ou une URL
• les glossaires
• les forums

Etant encore expérimentale, je cherche quelques testeurs et fournisseurs d'idées sur le sujet.

(suite à la discussion http://moodle.org/mod/forum/discuss.php?d=80815  )

Suite de la discussion et publication du patch dans le forum de développement :

http://moodle.org/mod/forum/discuss.php?d=81769