Dans le cadre de mon analyse technique des approches natives pour faire des learning analytics, je prends du temps pour analyser le plugin local_learning_analytics_log qui permet de stocker les données de log.

https://moodle.org/plugins/logstore_lanalytics

En base de données

Une fois activé, les actions sont enregistées dans la table mdl_logstore_lanalytics_log.
Il y a aussi une table mdl_logstore_lanalytics_evtname qui semble contenir la liste des événement à tracker avec un id (qui semble venir d’ailleurs car il n’est pas incrémenté).

Il est surprenant que la table mdl_logstore_lanalytics_log ne contienne que le champ contextid pour qualifier l’action, mais après analyse de la table mdl_context, je note qu’il est possible de remonter jusqu’à l’activité ciblée avec cette info.

J’essaie de comprendre comment une donnée entre dans ces tables …

Les fichiers qui permettent la création des la table de log sont dans le dossier
admin/tool/log/store/lanalytics
Dans le dossier db, je vois bien que l’install du plugin crée 2 tables.

La fonction qui semble remplir la table des événements est dans le fichier classes/log/store.php
C’est ce fichier qui permet d’enregistrer les données dans la table des logs de manière synthétisée.

Dans les tâches programmées, je vois seulement une tâche plutôt liée au nettoyage des données anciennes : \logstore_lanalytics\task\cleanup_task
qui doit sans doute se référer au fichier du même nom dans le dossier classes/tasks. C’est bien cette fonction qui supprime les données.
Je note que la suppression se fait sur base de la fonction delete_record_select(), il faut donc réussir à construire une requête SELECT pour retenir les éléments à supprimer …

Et pour savoir tester si cela fonctionne, je dois pouvoir lancer le cron manuellement. Quelques petites configs et cela devrait marcher …

To be able to run individual scheduled tasks via ‘Run now’ links on the scheduled tasks page, ‘Allow ‘Run now’ for scheduled tasks’ (tool_task | enablerunnow) in Site administration / Security / Site security settings should be enabled AND ‘Path to PHP CLI’ (pathtophp) in Site administration / Server / System paths should be set.

https://docs.moodle.org/403/en/Scheduled_tasks

Mais cela suppose aussi d’avoir configuré la commande PHP en local pour qu’elle pointe vers le php de MAMP.

Vers un plugin de log pour le flux social …

Install et stockage des infos

J’adapte facilement le plugin pour qu’il stoque les informations sur l’utilisateur qui a réalisé l’action et j’adapte les tables et les index pour mes besoins. Quand je fais des actions, les données entrent bien dans ma table de log. J’ai aussi ajouté un fichier install.php pour que les events liés aux activités par défaut de Moodle soient enregistrés dans le table des events trackés

Nettoyage des données obsolètes

J’adapte aussi le cleanup pour qu’il supprime uniquement les enregistrement souhaités : tous ceux liés à un contextid pour lesquels il n’y a plus eu d’action depuis 2 semaines.

Facile grâce à ChatGPT !

// Construire la sélection pour récupérer les actions à supprimer
$select = "date_action < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 2 WEEK)) 
            AND action NOT IN (SELECT DISTINCT action 
                                FROM {table_de_log} 
                                WHERE date_action >= UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 2 WEEK)))";

// Utiliser delete_records_select avec la sélection construite
delete_records_select('table_de_log', $select);

Quand je lance manuellement la tâche de cron liée au cleanup via l’admin Moodle, tout fonctionne bien. J’ai fait en sorte que la requête de suppression soit opérée par lot de 500 pour éviter de surcharger la base de données. Pour l’instant, j’ai configuré la suppression par lot de 50.
Le 21 mars après-midi, je devrai faire une action avec le compte de Harry Potter et vérifier que toutes les actions des autres utilisateurs sont supprimées de la table des logs.
Après une petite correction, je note que la suppression des données anciennes fonctionne bien.

La dernière version de mon plugin est disponible sur Github :
https://github.com/zabellemotte/moodle-socialflow-log

Données privées liées au plugin
Dans mon plugin, je stocke aussi des données utilisateur, donc je dois prévoir des infos dans les fonction privacy. Je dois m’inspirer de ce qui est fait dans le logstore standard de Moodle. Mais c’est pas simple.
Comme le comité me demande de mettre de côté les questions juridique pour l’instant, je vais avancer sur mon autre plugin et revenir plus tard à cette question.

Nombre de jours dédiés à cet article et au développement du plugin : 4 jours