Valery Fremaux

Votre solution peut-elle être du domaine technique (développement technique), ou seulement de l'intégration de solutions ? Ce n'est pas le même niveau de réflexion.

Tu veux dire, qui dérouleraient une partie de leur contenu dynamique dans le déroulé même du cours ?

Oui, je pense avoir compris ton besoin.

Apparemment c'est plus d'un bloc que tu as besoin que d'une activité (module). Un module dans Moodle est une micro application qui doit pouvoir être instanciée plusieurs fois dans un cours. C'est le cas d'une instance de ressource, mais aussi d'un forum.

Le code d'action d'un bloc qui affiche son contenu peut parfaitement faire ce travail de test du contenu d'un répertoire physique et de lister les fichiers modifiés. Le bloc utiliserait probablement un modèle de donnée (une table ou deux) pour :

• Déterminer en fonction du contexte (contexte du bloc au sens Moodle : cours, section générale) quel répertoire est concerné
• Enregistrer quelques métadonnées qui permettent d'enregistrer l'état de consultation (pour savoir ce qui est nouveau, il faut mémoriser ce qui est ancien).

Si ce dispositif doit être reproduit plusieurs fois et avec des paramètres différents dans le cours alors c'est bien d'un module dont tu as besoin, quoi qu'un bloc peut être utilisé en instances multiples (jamais testé) s'il est programmé pour le faire.

A partir du moment où tu ne cherches pas à partir de la page d'affichage du cours, (et que tu n'as donc pas besoin de "basculer" sur un écran de module) un bloc multiple te permet donc de lister ce que tu cherches dans une instance, et de configurer cette instance pour désigner le répertoire physique à prendre en charge. Si ce bloc est multiple, tu pourras en coller plusieurs dans les gouttières, chacun avec son paramètre fixé par l'administrateur du cours. 

Tout à fait exact Séverin. la fonction de Moodle intègre la localisation de l'utilisateur pour lui offrir des dates dans sa langue, sa locale et son fuseau. Les fonctions "legacy" du PHP ne proposent qu'un format  "international" technique qui convient moins bien à un affichage "grand public" où du moins humanisé.

Je rappelle que la forme YYYY-MM-DD est une représentation anglosaxone d'une date qui n'est pas conforme aux différentes règles historiques de typographie des dates en Français : DD/MM/YYYY On admet tout juste l'affichage des heures de type montre à quartz : HH:MM:SS que les règles françaises préfèrent afficher  HHhMM et SSsec.

Non, en fait ce n'est pas du tout comme ça que la liaison est faite.

1. Les champs student, students, teacher, teachers, ne servent qu'à stocker la "traduction locale" des termes "étudiant", "étudiants", "enseignant"', "enseignants" qui sont inscrit par défaut dans un nouveau cours. Ceci permet de modifier l'affichage dans un certain nombre de messages et de sorties à l'intérieur d'un espace de cours. Il y a de fortes chances que ces champs disparaissent à terme, car le nouveau système de rôle induit que certains cours utiliseront des schémas plus complexes, mais pour l'instant, c'est la seule façon de changer ces libellés.

2. L'assignation d'un utilisateur à un cours se fait par un jeu de tables : prefix_role (définit un role), prefix_role_capabilities (enregistre les valeurs de capacités pour chacun des rôles, chacun des capacités et chacun des contextes (donc grosse table, car table d'association entre tous les roles définis, tous les contextes et chacune des innombrables capacités individuelles réparties dans les modules et le code plus central), prefix_role_assignement permet d'attribuer un rôle à un utilisateur dans un certain contexte. Chaque fois qu'on inscrit un utilisateur pour faire quelque chose dans un cours, un module ou ailleurs par l'onglet "Roles", c'est là que ça se passe.

Enfin, la table prefix_context enregistre tous les contextes connus. Le principe est d'enregistrer une association entre un "niveau de contexte" et un "id" d'élément, à ce niveau. Ainsi, pour le niveau site c'est le niveau 10. Pour un module d'activité, c'est le niveau 70. Le numéro d'instance qui y est associé désigne donc pour chaque niveau quelque chose de différent : pour le niveau 70, l'id qui est associé est l'id d'un enregistrement de la table prefix_course_modules qui liste les instances des activités dans tous les cours.

Si on résume :

prefix_user -> prefix_role_assignement -> prefix_role
                  |
                  -> prefix_context WHERE contextlevel = 50 -> course

Voilà la relation de données qui te permet de savoir qui a un des rôles "legacy" (traduisible par "rôle historique") dans un cours Moodle.

PS : Attention, ceci n'est valable que depuis la mise en place des rôles en 1.7