Enf...é.
Je termine d'abord scheduler !!
Ca te branche Etienne ?
Je vous jure que je prépare pour le Moodle 2008 un atelier complet sur la synthèse d'un module, complet (prévoir 3 heures de conférence !!). Comme ça avec Etienne on couvre une partie de l'API de développement. Une bonne âme pour les filtres, une autre pour les thèmes, une dernière pour les formats de cours (moins populaire je pense) et on est majors.
Je l'installe ton module, rien que pour voir...
Pas d'accord 
Le propre d'un bon outil de la société de l'information, c'est de faire gagner du temps en prenant en charge un certain nombre de problèmes. Si enregistrer des rendez-vous (ce qui demande un certain effort et une rigueur des pratiques) produit un ensemble de données qui sont localement cohérentes, mais pas globalement, le risque de se faire "avoir" par un excès de confiance dans ses pratiques est grand. Il est justement de l'intérêt de l'outil de faire à ta place des vérifications qui sont fastidieuses à faire. Un rendez-vous à deux groupes d'étudiants en même temps pour le même prof et pour deux matières et contextes différents est une impossibilité "pragmatique". Le module doit donc pouvoir signaler ce type d'impossibilité : c'est précisément là qu'il travaille le mieux : le brassage systématique de données, alors que manipuler du sens est déjà pour lui beaucoup plus difficile.
En termes de difficulté "technique" il est étonnant de voir que, malgré quelques vérifications "d'effets de bord" à anticiper, la globalisation d'une vérification est extrêmement peu coûteuse d'un point de vue du programmeur : une simple règle à écrire différemment dans une requête.
Nous observons là encore une fois un effet de cette distorsion entre la complexité "fonctionnelle" apparente et le "modèle programmé" qui dit que ce qui simple à concevoir n'est pas nécessairement simple à faire, et vice-versa.
Il est tragique que nombre de nos décideurs "politiques" ou "institutionnels" ou simplement "hiérarchiques" ne parviennent toujours pas à le comprendre.
Bon, je me suis avancé.
En fait il faut reprendre la logique des conflits à 0. Le module a été fait "au minimum" pour ce qui est de cette logique. Dès qu'on passe à une limite "numérique" des rendez-vous, il faut plonger dans le code, et s'apercevoir de pas mal de faiblesses. J'en corrige quelques unes :
Du coup, les règles du module original sont trop faibles. Elles ne mesuraient qu'une contrainte locale dans le module.
Du coup c'est une grande partie de la librairie du module qui est à refaire. Cela prendra donc quelques jours.
1) Ouups !!
2) on peut négocier :
Limite le nombre de personnes sur un créneau multiple, c'est possible sans pb. J'ajoute.
Ajouter une note rédigeable par l'étudiant au moment de l'inscription. Si ça a des chances de servir, j'ajoute aussi. Je suis piloté par les usages, pas par la "théorie" ni le "dogme".
(à dans 2 heures...)
3) Ce commutateur est utile si on a rentré un paquet de créneaux par la division de période, et qu'on s'est planté. Beaucoup plus pratique de rebasculer les crénaux en mode groupe. Nous devrions voir progressivement arriver dans Moodle, de vraies pratiques systématiques de commandes "par lot". Elles sont cependant assez lourdes à mettre en place car elles demandent d'établir une solution généralisable. On trouve ces commandes par lot dans la gestion de fichiers par exemple. Le modèle est connu, mais chaque module demande une réflexion propre sur l'opportunité de ce type de transformations.