Après réflexion, il y reste 3 points d’amélioration pour le bloc de flux social :
– exclure les activités qui sont dans une section cachée (une jointure en plus sur course_sections.visible),
– exclure les activités liées à des cours cachés, (exclure ces cours de la sélection même s’ils sont dans les préférences utilisateur)
– prendre en compte d’une manière ou d’une autre les restrictions d’accès, le minimum étant de les afficher …

Les deux premiers points sont simples à prendre en compte mais le troisième mérite réflexion.

Prendre en compte les restrictions d’accès dans le flux social

L’idéal serait d’exclure les éléments auxquels l’étudiant n’a pas accès, mais ce n’est pas possible car le seul moyen pour savoir si l’étudiant a accès à un élément, c’est d’appeler une fonction php get_fast_modinfo qui parse le json des restrictions et qui dit si l’utilisateur a ou non accès à l’élement. Ce serait trop lourd de parser toute la table hits à chaque appel du flux social.

Donc les activités avec restriction d’accès seront affichées dans le flux social même si l’étudiant n’y a pas accès. Cela n’a pas de sens d’afficher les restrictions d’accès à l’étudiant, parce que parfois ces restrictions sont masquées à l’étudiant. Donc la solution est d’afficher les activités auxquelles l’étudiant n’a pas accès en grisé. Comme cela le nombre d’éléments reste cohérent, et l’info est claire pour l’étudiant.

Structure finale de la base de données

La version finale de la base de données intègre la table course_sections pour obtenir l’information sur la visibilité du cours. Les autres éléments ne changent pas.

Ultimes tests de performance

Test de l’ancienne requête de flux social :

WITH event_hits AS (
    SELECT 
        hl.courseid, hl.contextid, hl.eventid, hl.nbhits
    FROM 
        mdl_logstore_socialflow_hits hl 
    WHERE 
        hl.courseid IN (3186, 4353, 2402, 3552, 1631) 
        AND hl.lasttime > 1714138160 
)
SELECT 
    ei.contextid, 
    ei.eventid, 
    ei.courseid, 
    evts.actiontype, 
    c.instanceid, 
    cm.instance, 
    m.name, 
    CASE 
        WHEN ei.courseid = 3186 THEN CAST(ei.nbhits AS NUMERIC) / 321 
        WHEN ei.courseid = 4353 THEN CAST(ei.nbhits AS NUMERIC) / 261 
        WHEN ei.courseid = 2402 THEN CAST(ei.nbhits AS NUMERIC) / 765 
        WHEN ei.courseid = 3552 THEN CAST(ei.nbhits AS NUMERIC) / 279 
        WHEN ei.courseid = 1631 THEN CAST(ei.nbhits AS NUMERIC) / 362 
    END AS freq 
FROM 
    event_hits ei
INNER JOIN 
    mdl_logstore_socialflow_evts evts ON ei.eventid = evts.id 
INNER JOIN 
    mdl_context c ON ei.contextid = c.id 
INNER JOIN 
    mdl_course_modules cm ON c.instanceid = cm.id 
INNER JOIN 
    mdl_modules m ON cm.module = m.id 
WHERE cm.visible = 1
ORDER BY 
    freq DESC 
LIMIT 
    10;

En cette période de rentrée, l’ancienne requête prend 130 ms.

Test de la nouvelle requête de flux social (avec gestion des closingdates et des sections cachées) :

WITH event_hits AS ( 
    SELECT 
       h.id, h.courseid, h.contextid, h.eventid,   
       h.nbhits,h.userids 
    FROM 
        mdl_logstore_socialflow_hits h 
    INNER JOIN 
        mdl_logstore_socialflow_closing c 
    ON h.id=c.hitid 
    WHERE 
        h.courseid IN (3186, 4353, 2402, 3552, 1631) 
        AND h.lasttime >1714138160 
        AND c.closingdate>(1715347760+172800)
) 
SELECT 
    ei.id AS hitid, 
    ei.contextid, 
    ei.eventid, 
    ei.courseid, 
    evts.actiontype, 
    evts.moduletable, 
    evts.hasclosingdate, 
    evts.haslatesubmit, 
    evts.latedatefield,
    c.instanceid, 
    cm.instance, 
    m.name,
    ei.userids, 
CASE 
    WHEN ei.courseid = 3186 THEN CAST(ei.nbhits AS NUMERIC) / 321 
    WHEN ei.courseid = 4353 THEN CAST(ei.nbhits AS NUMERIC) / 261 
    WHEN ei.courseid = 2402 THEN CAST(ei.nbhits AS NUMERIC) / 765 
    WHEN ei.courseid = 3552 THEN CAST(ei.nbhits AS NUMERIC) / 279 
    WHEN ei.courseid = 1631 THEN CAST(ei.nbhits AS NUMERIC) / 362 
    END AS freq  
FROM event_hits ei 
INNER JOIN mdl_logstore_socialflow_evts evts 
ON ei.eventid = evts.id 
INNER JOIN mdl_context c ON ei.contextid = c.id 
INNER JOIN mdl_course_modules cm ON c.instanceid = cm.id INNER JOIN mdl_course_sections cs ON cm.section=cs.id INNER JOIN mdl_modules m ON cm.module = m.id 
WHERE cm.visible = 1 AND cs.visible=1 
ORDER BY freq DESC 
LIMIT 10; 

Avec les nouvelles jointures, cela prend de l’ordre de 200 ms.
Cela reste tout-à-fait raisonnable.

Les autres requêtes n’ont pas évolué, donc c’est inutile des les retester.

Les performances me semblent bonnes !

Cela me permet de finaliser ce projet.

Après une série de vérifications du fonctionnement de l’outil, je poste mes deux plugins sur GitHub:
https://github.com/zabellemotte/moodle-socialflow-log
https://github.com/zabellemotte/moodle-socialflow-block

Temps de travail sur cet article et les développements associés : 2 jours