Skip to Content

Projet Niveau 3 — Module d’activité noté mod_simplecheck

⏱️ TL;DR — Le type de plugin le plus riche : un module d’activité. Vous construisez mod_simplecheck, une « checklist notée » complète, avec toute la mécanique mod : mod_form, view.php, les fonctions add/update/delete_instance, les FEATURE_*, l’intégration au carnet de notes, l’achèvement d’activité, les events, et le backup/restore. Objectif : maîtriser le contrat le plus exigeant de Moodle — celui qui prouve que vous savez développer sérieusement pour la plateforme.

🎯 Niveau & objectifs

  • Niveau : 3 (avancé). Prérequis : Niveau 2 (vous savez faire un local et un block).
  • Durée indicative : 12–20 h (le plus long du parcours).
  • Vous allez pratiquer : structure mod, mod_form.php, lib.php (_add_instance/_update_instance/_delete_instance, supports()/FEATURE_*), view.php, grade_update (carnet de notes), achèvement custom (classes/completion/custom_completion.php), events (\core\event), backup/restore (backup/moodle2/), reset de cours, cm_info.

📋 Cahier des charges

Contexte — Les formateurs veulent une activité « checklist » : l’apprenant coche des items, et l’activité produit une note et un achèvement exploitables comme n’importe quelle activité Moodle native.

Objectif — Un module d’activité complet, indiscernable d’un module natif du point de vue de Moodle (notes, complétion, sauvegarde, logs).

Périmètre inclus

  1. Structure mod/simplecheck/ conforme : version.php, db/install.xml, db/access.php, lib.php, mod_form.php, view.php, index.php, lang/en/.
  2. mod_form.php : réglages de l’instance (liste d’items de la checklist, note max).
  3. lib.php : simplecheck_add_instance / _update_instance / _delete_instance, et simplecheck_supports() déclarant les FEATURE_* (grade, completion, backup, groups…).
  4. Persistance des items et des cases cochées par utilisateur (tables XMLDB).
  5. Carnet de notes : la complétion de la checklist produit une note via grade_update (simplecheck_grade_item_update, simplecheck_update_grades).
  6. Achèvement d’activité : une règle custom « X % des items cochés » (custom_completion).
  7. Events : déclencher course_module_viewed et un event custom au « complété ».
  8. Backup/restore (backup/moodle2/) : l’activité et ses données survivent à une sauvegarde/restauration.
  9. Affichage sur la page de cours correct (cm_info / icône).

Périmètre exclu — Pas de web service ni de front externe (Niveau 4), pas de LTI (Niveau 5), pas de sous-plugins.

Contraintes

  • Chaque FEATURE_* déclaré doit être réellement implémenté (pas de true menteur).
  • Sécurité : pattern complet, require_login($course, true, $cm), capabilities, sesskey.
  • Les données doivent survivre à un backup → restore dans un autre cours.
  • Aucun message en mode débogage développeur.

Livrables

  • Le dossier mod/simplecheck/.
  • Une note : « pour chaque FEATURE_*, où est-ce implémenté ».

✅ Critères de réussite

  • On peut créer une instance, définir des items, l’enregistrer, l’éditer, la supprimer sans résidu.
  • Un apprenant coche des items ; sa progression est persistée par utilisateur.
  • Une note apparaît dans le carnet de notes et se met à jour.
  • L’achèvement custom passe à « terminé » selon la règle définie.
  • Les events apparaissent dans les logs du cours.
  • Un backup → restore dans un autre cours recrée l’activité et ses données.

🗺️ Endroits à visiter

EndroitPourquoi y aller
Code du cœur : mod/choice, mod/assignfilesystemLes meilleurs modèles ; choice est simple, assign complet
FEATURE_* (doc)Activity modules API La liste des capacités déclarables + leurs implications
Grade APIGrades API grade_update, grade_item, comment une note remonte
Completion APICompletion custom_completion, les états d’achèvement
Events APIEvents Déclarer/déclencher un event \mod_simplecheck\event\...
Backup/restoreBackup API backup/moodle2/backup_*_stepslib.php : le plus déroutant
Générateur mod skeletontools Squelette mod conforme pour démarrer
Carnet de notes du coursCours → NotesVérifier que votre note remonte correctement

💡 Pour un dev React — Le module mod est le framework dans le framework : un composant à cycle de vie complet (add/update/delete_instance ≈ create/update/destroy), branché sur des subsystems transverses (notes, complétion, events, backup). Le piège n’est pas la difficulté d’un fichier, mais le nombre de contrats à honorer simultanément. Traitez chaque FEATURE_* comme une interface à implémenter réellement : déclarer une capacité qu’on n’implémente pas casse Moodle en silence.

⚠️ Piège — Le backup/restore est la partie la plus négligée et la plus testée en review sur moodle.org. Un module qui ne se sauvegarde pas correctement perd les données de vos utilisateurs lors d’une restauration : implémentez et testez réellement un cycle backup → restore dans un autre cours avant de considérer le projet fini.

🚀 Étapes suggérées

  1. Squelette mod/simplecheck ; version.php, lang/, install.
  2. Tables XMLDB (config d’instance + items + cochage par user).
  3. mod_form.php + add/update/delete_instance ; créer une instance.
  4. view.php : afficher la checklist, enregistrer les coches (sécurisé).
  5. supports() + FEATURE_* ; brancher le carnet de notes (grade_update).
  6. Achèvement custom (custom_completion).
  7. Events + vérifier les logs.
  8. Backup/restore ; tester un cycle complet.

🎁 Bonus

  • Ajoutez le reset de cours (simplecheck_reset_userdata).
  • Ajoutez un privacy provider (données personnelles des coches).
  • Écrivez un test PHPUnit sur add_instance + un scénario Behat de coche (Partie 11).

🔗 Chapitres du cours liés


Projet suivant : Niveau 4 — Web services + dashboard Next.js.